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EXECUTIVE  SUMMARY 


This  technical  report  describes  how  to  develop  a  specification  of  software  requirements  using  the 
Software  Productivity  Consortium  Requirements  Engineering  (CoRE)  software  requirements 
method  firom  a  system  requirements  and  design  specification  developed  using  Ascent  Logic 
Corporation’s  RDD-100.  Specifically,  this  report  describes  the  transition  from  system  design  to 
software  requirements  analysis  when: 

•  RDD-100  has  been  used  to  create  system  requirements  and  design  specifications. 

•  The  software  requirements  analysis  activity  is  to  be  performed  according  to  the  CoRE 
method. 

RDD-100  is  the  implementation  of  the  Requirements  Driven  Design  (RDD)  system  design  and 
engineering  method  (Ascent  Logic  Corporation  1992a),  wherein  the  system  design  is  driven  by  the 
customer’s  expectations  of  system  behavior.  CoRE  is  the  Software  Productivity  Consortium’s 
software  requirements  engineering  method  (Software  Productivity  Consortium  1993)  aeated  to 
support  the  development  of  predse,  testable  spedfications  that  are  demonstrably  complete  and 
consistent. 

An  RDD-100  system  model  contains  all  of  the  information  needed  to  begin  building  a  CoRE  software 
requirements  spedfication.  This  report  describes  a  process  and  guidelines  for  building  a  CoRE 
software  requirements  spedfication  from  an  RDD-100  system  model.  The  process  consists  of  the 
following  high-level  activities: 

•  Identifying  sources  of  the  necessary  CoRE  information  in  the  RDD-100  model 

•  Mapping  that  information  to  an  initial  CoRE  spedfication 

•  Completing  the  CoRE  specification 

The  Consortium’s  experience  in  the  use  of  CoRE  with  RDD-100  is  based  on  the  development  of  a 
CoRE  spedfication  of  software  requirements  for  the  Host-at-Sea  (HAS)  Buoy  problem  from  an 
RDD-100  model  of  system  requirements  and  design.  Hie  guidance  provided  in  this  report  documents 
the  Consortium’s  oqieriences  and  lessons  learned  from  this  case  study. 
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1,  INTRODUCTION 


The  RDD-100  tool  was  developed  to  support  a  systems  engineering  |Mrocess  wherein  the  system  design 
is  driven  the  customer’s  expectations  of  system  behavior.  The  Consortium  Requirements  Engineer¬ 
ing  (CoRE)  method  is  a  soft^re  requirements  en^neering  method  supporting  the  development  of 
precise,  testable  specifications  that  are  demonstrably  complete  and  consistent.  The  Requirements 
Driven  Design  (l^D)  systems  engineering  methodology  supported  by  RDD-100  is  generally 
anrdatedto  die  CoRE  method,  meaning  diat  aiqr<hrect  support  from  RDD-100  forCo]^  is  coind- 
dmital.  Tlierefore,  the  best  approadi  to  using  RDD-100  a^  CoRE  together  is  to  determine  how  to 
transition  from  ^tem  spedfication  using  RDD-100  to  software  requirements  analysis  using  CoRE. 

1.1  PURPOSE  OF  THIS  REPORT 

Tlie  purpose  of  this  report  is  to  desoibe  how  best  to  develop  a  CoRE  software  requirements 
spedfication  from  an  RDD  system  design  model  developed  using  RDD-100.  That  is,  given  an 
IWD-lOO  model  of  system  requirements  and  design,  this  report  desaibes  how  one  can  most 
effectively  develop  a  specification  of  software  requirements  using  the  CoRE  method.  Cadre’s 
teamworfc  can  be  used  to  build  a  CoRE  software  requirements  specification  and  is  assumed  to  be  the 
tod  of  choice  for  the  CoRE  practitioner. 

An  RDD-100  ^tem  model  contains  all  of  the  information  needed  to  begin  building  a  CoRE  software 
reqmrements  spedfication.  This  report  describes  a  process  and  guidelines  for  building  a  CoRE 
software  requirements  spedfication  from  an  RDD-100  system  model.  The  process  consists  of  the 
fr)llowing  activities: 

•  Use  Ascent  Logics  Extender  to  extend  the  RDD-100  database  schema  so  that  it  recognizes 
Core  elements  (optional). 

•  Given  an  RDD-100  model  of  system  requirements  and  design  from  systems  engineering, 
identify  those  parts  of  the  model  that  systems  engineers  need  for  CoRE  (making  tise  of  the 
extended  RDD-100  database  schema  if  possible). 

•  Generate  a  report  from  the  RDD-100  model  to  fadlitate  mapping  to  CoRE  elements 
(optional). 

•  Filter  the  RDD-100  model  into  ttsaawork  using  Ascent  Logic’s  teamwork  bridge  (optional). 

•  Create  an  initial  CoRE  spedfication  from  the  RDD-100  model  (using  the  generated 
teamwork  model  and/or  CoRE  report  to  facilitate  if  possible). 


Com|dete  the  CoRE  spedfication  and  begin  software  design. 


1.  IntRxhicticm 


Both  the  Core  method  and  RDD-100  tool  are  continually  evolving  to  include  new  features  and 
capabilities.  This  report  is  based  on  the  Consortium  Requirements  Engineering  Guidebook,  version 
01.00.09  (Software  Productivity  Consortium  1993)  and  RDD-100,  release  3.0.2  (Ascent  Logic 
Corporation  1992a).  Subsequent  versions  of  this  report  will  encompass  additional  features  of 
enhanced  versions  of  CoRE  and  RDD-100.  Release  4.0  of  RDD-100  was  delivered  during  the 
production  of  this  report. 

1,2  BACKGROUND 

Figure  1  presents  a  simplistic,  high-level  view  of  the  activities  performed  in  developing  a  system.  First, 
the  system  requirements  are  analyzed,  and  then  a  system  design  is  created  by  allocating  requirements 
to  hardware  and  software  components.  Then,  hardware  and  software  development  occurs  in  parallel. 
This  report  is  only  concerned  with  software  development.  Software  development  consists  of  three  acti¬ 
vities:  requirements  analysis,  design,  and  implementation.  This  report  desaibes  the  transition  from 
^tem  design  to  software  requirements  analysis  when  both  of  the  following  are  true: 

•  RDD-100  has  been  used  to  create  system  requirements  and  design  spedfications. 

•  The  software  requirements  analysis  activity  is  to  be  performed  according  to  the  CoRE 
method. 


I^gurel.  System  Devdopment  Activities 

The  diaded  region  in  Figure  1  identifies  those  activities  of  system  development  that  are  addressed  1^ 
this  report  A  small  portion  of  the  system  design  box  is  shaded  because,  near  the  end  of  system  design, 
some  information  not  traditionally  provided  by  an  RDD-100  specification  can  be  provided  to  ease  the 
transition  to  software  requirements  analysis  using  CoRE.  The  entire  software  requirements  analysis 
box  is  shaded  because  a  significant  portion  of  the  CoRE  method  is  affected  by  the  use  of  an  RDD-100 
specification. 

13  QUESTIONS  TO  BE  ANSWERED 

Ttus  repcMTt  is  intended  to  provide  detailed  answers  to  the  following  questions: 

•  Given  an  RDD-100  specification  of  system  requirements  and  design,  how  can  an  engineer 
most  effectively  develop  a  specification  of  software  requirements  using  the  CoRE  method? 
(An  engineer  can  use  the  approach  shown  in  Figure  2  and  described  throughout  the  remaining 
sections  of  the  report.) 
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1.  IntroductiM 


•  Does  the  RDD-lOO  ^tem  specification  contain  all  the  information  an  engineer  needs  to  build 
a  Core  specification?  (Yes,  see  Section  3.2.) 

•  How  does  an  engineer  map  system  requirements  expressed  in  RDD-lOO  to  CoRE?  (See 
Sectimi  33.) 

•  Can  the  RDD-lOO  database  schema  be  extended  to  include  the  CoRE  sdiema?  (Yes,  however. 
Ascent  Logic’s  Abstract  Object  Editor  provides  better  suf^rt  for  the  CoRE  schema,  as 
described  in  Section  4.) 

•  Can  a  CoRE  spedfic  report  be  generated  using  RDD-lOO’s  Report  V^ter  that  will  facilitate 
the  development  of  a  CoRE  specification  fi'om  an  RDD-lOO  model?  (Yes,  as  described  in 
Section  5.) 

•  Can  the  RDD-lOO  bridge  to  ttsamvork  support  an  automated  transition  fi’om  an  RDD-lOO 
system  design  to  a  CoRE  software  requirements  activity  using  teamworfe?  (Yes,  as  desoibed 
in  Section  6.) 

This  report  answers  these  questions  and  includes  a  supporting  example. 

1.4  INTENDED  AUDIENCE 

This  report  is  intended  to  guide  software  requirements  engineers  in  developing  a  CoRE  spedfication 
fiom  an  RDD-lOO  ^tem  spedfication.  The  systems  engineer  using  RDD-100  to  develop  a  ^tem 
design  can  use  this  report  to  help  identify  the  kinds  of  information  that  a  software  requirements  engi¬ 
neer  using  CoRE  would  expect  to  find  in  the  RDD-lOO  model,  thus  allowing  smoother  transition  fiom 
^tem  design  to  software  requirements  and  design.  This  report  can  be  used  by  process  and  method 
developers  to  help  describe  an  engineering  process,  including  both  the  RDD-lOO  tool  and  the  CoRE 
method 

It  is  assumed  that  readers  of  this  report  have  a  fundamental  understanding  of  RDD-lOO  and  CoRE. 
Although  this  report  contains  brief  overviews  of  RDD-lOO  and  CoRE,  readers  should  be  familiar  with 
RDD-lOO  Usefs  Guide  (Ascent  Lq^c  Corporation  1992a)  and  Consortium  RequiranentsEr^ineamg 
Guidebook  (Software  Productivify  Consortium  1993)  before  reading  this  report 

1.5  ORGANIZATION  OF  THIS  REPORT 
The  remainder  of  the  report  is  organized  as  follows: 

•  Section  2  provides  overviews  of  RDD-lOO  and  CoRE  and  compares  and  contrasts  them. 

•  Section  3  describes  an  approach  for  deriving  a  CoRE  software  requirements  spedfication 
fiom  an  RDD-lOO  ^tem  design  specification.  It  describes  where  to  look  in  the  RDD-lOO 
model  for  information  needed  1^  CoRE  and  describes  how  to  build  the  CoRE  model  fiom  the 
RDD-lOO  specification. 

•  Section  4  describes  how  ^tems  engineers  might  extend  the  standard,  underlying  database 
schema  of  RDD-lOO  so  that  it  recognizes  CoRE  constructs  and,  therefore,  facilitates  mapping 
fiom  an  RDD-lOO  model  to  a  CoRE  model. 


1.  Imrotelioa 


•  Section  5  desaibes  a  CoRE  specific  report  that  can  be  generated  using  RDD-lOO’s  Report 
Writer  to  facilitate  the  development  of  a  CoRE  specification  from  an  RDD-100  model. 

•  Section  6  describes  how  to  use  the  RDD-lOO  bridge  to  Cadre’s  teamwoffc/RT  tool  for  those 
using  teamivorA/Rr  to  build  a  CoRE  specification. 

•  The  ^pendiz  contains  selected  examples  from  the  Host-at-Sea  (HAS)  Bu<^  system  case 
stwfy  that  illustrate  the  approach  described  in  this  report. 

1.6  TYPOGRAPHIC  CONVENTIONS 

This  report  uses  the  following  ^pographic  conventions: 


Serif  font .  General  presentation  of  information. 

/m&zzei  sen/font .  PtiUication  titles  and,  in  the  Appendix,  element 

relationships  and  attributes. 

Boldfaced  serif  font . Section  headings  and  emphasis. 

BoUgbcedUalicizied  seiif  font .  Run-in  headings  in  bulleted  lists  and,  in  the  Appendix, 

minor  subsections. 

BaUdzedsem  serif  font  .  RDD-100  element  names. 

Typewriter  font .  Syntax  of  code  or  software  responses. 
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2.  OVERVIEW 


This  section  provides  an  overview  of  the  |»’ocess  and  framework  upon  which  the  remainder  of  the 
report  is  based.  The  proposed  process  for  developing  a  CoRE  specification  from  an  RDD-100 
specification  is  o(»np(»ed  of  the  following  activities: 

•  Use  Ascent  Lc^c’s  Extender  to  extend  the  RDD-100  database  sdtema  so  that  it  recognizes 
Core  elements  (optional). 

•  Given  an  RDD-100  model  of  system  requirements  and  design  from  systems  engineering, 
identify  those  parts  of  the  model  that  systems  ei^neers  need  for  CoRE  (making  use  of  the 
extended  RDD-100  database  schema  if  possible). 

•  Generate  a  report  from  the  RDD-100  model  to  facilitate  mapping  to  CoRE  elements 
(optional). 

•  Hlter  the  RDD-100  model  into  teamwork  using  Ascent  Logic’s  teamwork  bridge  (optional). 

•  Create  an  initial  CoRE  specification  from  the  RDD-100  model  (using  the  generated 
teamworfc  model  and/or  CoRE  report  to  fadlitate  if  possible). 

•  Comjdete  the  CoRE  specification  and  begin  software  design. 

F^ure  2  illustrates  the  propoc?d  process  and  shows  how  it  fits  into  the  ^tem  development  process 
illustrated  in  Figure  1.  ]^es  represent  activities,  and  arrows  indicate  sequencing;  iteration  is  implicit 
and  is  not  shown.  External  activities  are  those  performed  as  usual,  regardless  of  the  use  of  the  pro¬ 
posed  (xrocess  (although  some  assumptions  must  be  made  about  the  RDD-100  system  design  model, 
as  desoibed  in  Section  3.1).  Required  and  optional  activities  are  those  activities  performed  specifical¬ 
ly  wiien  building  a  CoRE  specification  from  an  RDD-100  system  design  model,  as  describe  in  this 
rq;x>rL 

Although  Figure  2  does  not  illustrate  it,  the  process  is  iterative,  meaning  that  the  sequence  of  activities 
may  be  repetitive  (i.e.,  all  arrows  in  Figure  2  are  really  bidirectional).  For  example,  after  building  an 
initial  CoRE  spedfication,  ^tems  engineers  might  decide  to  revisit  fte  Identify  CoRE  Inputs  activity 
because  of  the  acquisition  of  new  or  darifying  information. 

The  remainder  of  this  section  provides  context  for  the  remainder  of  this  report.  Sections  2.1  and  22 
describe  the  relevant  features  of  RDD-100  and  CoRE,  respectively.  S^on  23  compares  and 
contrasts  RDD-100  and  CoRE. 

IX  RDD-100 

RDD-100  is  the  implementation  of  the  RDD  system  design  and  engineering  method  (Ascent  Logic 
Corporation  1992a).  RDD  encompasses  both  an  empirically  derived  method  for  designing  :^tems 
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and  the  rigorous  use  of  a  structured,  executable  language  that  implements  an 
entity-relationship-attribute  (ERA)  data  model  for  the  systems  engineering  database.  Because  of  the 
generality  allowed  by  the  ERA  data  model,  RDD-100  is  equally  at  home  whether  used  to  model  an 
enterprise,  a  manufacturing  process,  a  large  communications  system,  a  subsystem,  or  relatively 
low-level  behaviors,  such  as  communications  protocols.  RDD-100  has  implemented  the  ERA  model 
uang  an  object-oriented  database,  which  contains  only  one  instance  of  the  tystem*s  descriptive  data 
and  provides  multiple  views  of  the  data  for  the  design  and  analysis  activities. 


Automated  components  of  RDD-100  that  are  of  particular  interest  include  (O’Rourke  1993): 


•  Element  Editor.  Provides  an  interactive  mechanism  for  spedfying  and  traversing  RDD-100 
database  elements,  their  attributes,  and  relationships  between  them. 

•  Requiranents  Extractor.  Facilitates  the  specification  of  a  system  requirement  hierarchy  by 
extracting  portions  of  requirements  documents. 

•  Graphics  Editor.  Permits  engineers  to  describe  the  dynamic  properties  of  systems  using  a 
graphics  language  describing  behavior  in  terms  of  the  time  sequences  of  inputs,  functions,  and 
outputs. 

•  Dynamic  Variation  Facility.  Provides  dynamic  execution  of  the  system  specification  as  a 
discrete  event  simulation  from  within  the  systems  engineering  database. 

•  Extender.  Allows  the  user  to  extend  the  underlying  ERA  database  schema  of  RDD-100  to 
accommodate  more  spedalized  needs  (e.g.,  the  engineering  change  proposal  process  or  the 
proposal  development  process). 


2.  Overview 


•  Report  Writer.  Allows  the  generation  of  predefined  or  tailored  reports  from  the  RDD-100 
database. 

•  Teomweerk  BrU^.  Automatically  generates  a  teomwork  model  from  an  RDD-100  database. 

This  section  provides  a  high-level  description  of  RDD-lOO’s  systems  engineering  method  (see  Section 
2.1.1)  and  data  model  (see  Section  2.1.2)  to  establish  a  framework  for  subsequent  sections. 

Release  4.0  of  RDD-100  provides  additional  tools  for  manipulating  the  contents  of  the  database, 
including  a  multielement  editor  and  abstract  object  modeling.  Section  2.13  provides  a  brief  overview 
of  how  those  capabilities  may  be  useful  for  CoRE  spedfications.  However,  the  details  of  Release  4.0 
capabilities  are  beyond  the  scope  of  this  paper. 

2.1.1  ROD-100  Method 

RDD,  the  method  underlying  the  RDD-100  tool,  is  aimed  at  finding  a  way  to  develop 
high-performance,  hi^-reliability  systems  composed  of  hardware,  software,  and  people.  O'Rourke 
(1993)  describes  the  RDD-100  method  as  a  process  wherein  the  system  design  is  driven  by  the 
customer’s  expectations  of  a  system  behavior,  w4udi  is  traced  directly  to  ^tem  requirements  and 
their  original  source.  The  system  design  is  expressed  as  an  allocation  of  system  behaviors  (functions) 
onto  the  various  components  that  will  compose  the  implemented  system. 

O’Rourke  (1993)  describes  the  RDD-100  method  as  the  following  set  of  activities: 

«  Define  the  engineering  problem  and  system  boundaries. 

•  Define  a  candidate  component  architecture. 

•  Extract  and  index  requirements;  describe  desired  behavior. 

•  Decompose  and  allocate  behavior  to  components  (i.e.,  hardware,  software,  people,  etc.). 

•  Identify  and  specify  interfaces. 

•  Perform  feasibility  and  tradeoff  analysis. 

•  Describe  failure  mode  behavior. 

•  Flan  system  integration  and  test. 

•  Optimize  design. 

•  Generate  spedfications  and  documentation. 

•  Perform  verification  and  validation  against  aq}ected  behavior. 

In  the  contOEt  of  this  report,  the  first  three  activities  in  the  above  list  are  considered  ^tem 
requirements  activities.  The  remaining  activities  are  part  of  the  ^tem  design  i^ocess. 

2.1.2  RDD-100  Model 

The  RDD-100  model  indudes  two  kinds  of  elements:  those  that  are  part  of  the  system  requirements 
model  and  those  that  are  part  of  the  system  design  model.  RDD-100  intern  requirements  elements 
of  interest  for  this  report  include  the  following  (Ascent  Logic  Corporation  1992a,  1993a): 
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•  Sourc0  records  the  paper  input  to  the  system  design  process. 

•  Systemf^uiretnent  is  a  detailed  functional,  performance,  and  interface  requirement  derived 
over  the  life  of  the  system  specification  process. 

•  CiUcalbsw  is  a  problem,  issue,  or  limitation. 

•  Decision  is  a  dioice  that  has  been  made  to  establish  requirements  based  on 
SystemReqiMrements. 

•  Peifonnanceindex  is  a  quantifiable  performance  limitation  or  objective. 

•  ConstraM  is  a  required  quality  or  resource  limitation  on  other  elements. 

•  SystemParameter  is  an  operating  parameter  that  may  affect  cost  and/or  performance  during 
devdopoimt  and/or  c^xtf'atkm. 

figure  3,  derived  fi-om  Ascent  Logic  Corporation  (1993a,  1.5*- 1.13),  illustrates  the  fundamental 
elements  and  relationships  underlying  the  RDD-lOO  model  of  system  requirements.  All  of  the 
relationships  in  IHgure  3  are  bidirectional:  arrowheads  are  used  to  identify  the  directions  implied  by 
the  relationship  names. 


Figure  3.  The  RDD>100  System  Requirements  Model 


RDD-100  ^tem  design  elements  of  interest  for  this  report  include  the  following: 

•  Items  are  model-observable  inputs  and  outputs  that  arrive  at  or  depart  from  the  system. 
-  Dhcret^em  arrives  as  a  unit,  represents  the  limit  of  observability. 

—  Tlmeltem  is  a  class  of  legal  sequences  of  Discreteltems. 
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•  Fiiiu:tions  transform  arriving  items  into  departing  items. 

-  tXacnt^iuKiion  transforms  one  0/screte/ltem  into  an  unordered  collection  of 
Dbcr^9Hem&. 

-  Tin^HmcHon  is  an  aggregation  of  Discr^eFuncUons  or  TImeFunctions  that  transforms 
an  ordered  collection  of  Discr^0ttems  or  Timeltems  into  an  ordered  collection  of 
Dbcnteltmis. 

•  Component  is  one  of  the  parts  (hardware,  software,  or  human)  in  a  system,  for  example,  a 
sub^tenL 

•  Graphic  constructs  represent  concurrency,  iteration,  loops,  conditions,  selection,  and 
replication. 

-  INet  represents  sequences  of  inputs  or  outputs. 

-  FNet  represents  sequences  of  behavior  (functions). 

•  ItemUnk  is  a  logical  pathway  that  canies  a  message  item  from  one  RDDProcess  to  another. 

•  ExtemalSystem  is  a  separate  system  outside  the  required  ^tern’s  boimdary. 

•  Interface  is  a  mechanism  for  items  to  flow  aaoss  the  system  boundary  or  from  one  component 
to  another. 

Figure  4  illustrates  the  fundamental  elements  and  relationships  underlying  the  RDD-100  model  of 
system  design.  The  legend  identifies  the  names  of  the  relationships  that  identify  how  the  source 
elements  on  the  left  side  of  Figure  4  relate  to  the  target  elements  on  the  right  side  of  Figure  4. 

2.13  RDD'lOO  Release  4 

The  following  new  products  from  Release  4  of  RDD-100  may  provide  improved  support  for  CoRE: 

•  Mutti-Elemait  View.  Provides  the  abilify  to  view  and  edit  multiple  RDD-100  database  elements 
and  relationships  in  a  single  window.  Among  other  advantages,  this  tool  should  facilitate 
decomposition  of  Source  documents  into  hierardiies  of  SystemRequIrements. 

•  Abstract  Object  Editor  (and  Beat  World  Object  E^r).  FTovidestheability  to  overlay  a  database 
schema  on  top  of  the  existing  one.  This  tool  allows  the  user  to  tailor  an  RDD-100  model  for 
methods  sudi  as  CoRE  and  obviates  the  need  to  modify  the  RDD-100  database  sdiema,  as 
described  in  Section  4. 

A  future  release  of  this  report  will  discuss  Release  4.0  of  RDD-100  in  detail. 

23  Core 

Core  is  a  method  for  analyzing,  capturing,  and  specifying  software  requirements  (Software 
Froductivify  Consortium  1993).  The  Consortium  has  worked  with  industrial  developers  of  real-time 
and  embedded  ^tems  to  provide  a  method  that  addresses  their  needs.  CoRE  supports  the 
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Figure  4.  Hie  RDD*100  System  Design  Model 


development  of  precise  testable  spedfications  that  are  demonstrably  complete  and  consistent.  CoRE 
also  supports  key  process  issues,  such  as  managing  dianging  requirements  and  reuse.  CoRE  is  a  single, 
coherent  requirements  method  that: 


•  JMegrates  ObJea-OrientedcmdFbniudModds.  ACoRE  spedfication  organizes  the  details  of  the 
behavioral  model  into  classes  of  objects,  whidi  provides  a  mechanism  for  abstraction,  separa¬ 
tion  of  concerns,  and  information  Uding.  Systems  engineers  use  the  CoRE  class  structure  to 
address  objectives  like  change  management  or  reuse. 


•  lat^rafes  GrapMeal  and  Kgorous  Speeifieadons.  Graphic  representation  helps  all  parties  (e.g., 
customers,  engineers,  designers,  and  programmers)  to  grasp  essential  relationships  among 
^tem  components.  CoRE  {nrovides  a  consistent,  rigorous  interpretation  of  both  graphical 
and  mathematical  notations.  This  allows  the  graphical  specifications  to  combine  smoothly 
with  the  detailed  specifications  that  are  best  given  in  mafiiematical  and  textual  notation. 


•  Uses  Exiai^  Skins  and  Notations.  The  language  used  to  spedfy  requirements  in  CoRE  is  based 
on  familiar  concepts  and  existing  notations. 


*  Fermits  NonalgorUhnuc  Specifieadon.  CoRE  is  nonalgorithmic  in  the  sense  that  ^tems 
engineers  can  specify  the  required  behavior  of  a  ^tem  without  having  to  provide  an  algorithm 
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or  detailed  design;  i.e.,  systems  engineers  can  always  specify  the  behavior  in  terms  of  what  the 
system  must  do  rather  than  how  it  does  it. 

•  Provides  Guidance.  The  CoRE  process  model  ju^ovides  practical  guidance  in  developing  both 
the  object  structure  and  the  behavioral  requirements.  The  behavioral  model  provides  a  stan- 
dardi^  structure  that  helps  the  developer  determine  the  class  structure.  Tlie  behavioral 
model  also  forms  the  basis  of  a  systematic  process  for  developing  a  complete  requirements 
specification. 

Requirements  in  CoRE  are  written  in  terms  of  two  underlying  models:  the  behavioral  model  and  the 
class  model.  The  CoRE  process  describes  the  order  in  «4uch  the  specification  is  composed,  the  behav¬ 
ioral  model  captures  what  the  software  must  do,  and  the  dass  model  organizes  that  information.  Sec¬ 
tion  2.2.1  provides  an  overview  of  the  CoRE  process.  Section  2.2.2  describes  the  behavioral  model, 
and  Section  2.23  desaibes  the  class  model. 

2.2.1  Core  Process  Overview 

The  CoRE  process  is  a  sequence  of  activities  that  systems  engineers  follow  to  develop  a  CoRE 
requirements  specification.  The  CoRE  process  is  driven  by  two  concerns.  The  first  concern  is  the 
step-by-step  construction  of  a  required  behavior  spedfication  in  terms  of  the  CoRE  behavioral  model 
for  a  partic^ar  ^tem.  The  goal  is  to  develop  a  complete  and  consistent  deso’iption  of  the  required 
behavior.  The  second  concern  is  the  step-by-step  packaging  of  spedfication  pieces  in  elements  of  the 
dass  structure.  This  aspect  of  the  meth^  satisfies  padcaging  goals,  such  as  change  management  and 
reuse.  Because  packaging  and  spedfication  activities  overlap  in  time,  the  threads  of  these  activities 
are  intertwined  in  the  CoRE  method. 

The  input  to  the  CoRE  process  is  some  form  of  system  requirements  spedfication  (i.e.,  the  first 
activi^,  identifying  system  constraints,  assumes  that  a  ^tem  spedfication  is  available).  The  output 
of  the  CoRE  process  is  a  complete  spedfication  of  the  software  requirements  (i.e.,  suitable  for  a 
software  design  process). 

The  CoRE  process  is  a  description  of  an  *‘idear  process.  The  process  is  idealized  rather  than  “real” 
in  that  it  do^  not  account  for  errors,  requirements  dianges,  unknown  requirements,  or  other  factors 
requiring  additional  iteration,  «q)erimentation,  or  backtracking.  An  ideal  process  is  useful  because 
it  provides  an  otemal  standard  to  guide  development  and  it  serves  as  a  yardstick  for  measuring 
progress.  Thus,  the  ideal  CoRE  process  is  divided  into  a  sequence  of  five  activities: 

•  Idmdfy  Emnronmentai  Varieddes.  Systems  engineers  identify  candidate  environmental 
variables  and  the  relations  among  them.  The  overall  goal  is  to  identify  environmental 
quantities  that  denote  the  monitored  and  controlled  variables,  relationships  that  will  become 
parts  of  the  required  (REQ)  and  natural  (NAT)  relations,  and  relationships  that  will  become 
part  of  the  generalization/specialization  structure.  Identify  likely  changes  and  their  impacts 
on  these  environmental  variables. 

Prdimimry  Bduivior  Spec^kation,  ^tems  engineers  identify  and  spedfy  the  monitored  and 
controlled  variables.  Ihey  identify  undesired  ewnts  to  which  the  system  must  respond  and  de¬ 
fine  monitored  variables  to  denote  them.  Th^  identify  the  domain  and  scheduling  fype  for 
each  controlled  variable  and  identify  modes. 
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•  Class  Struettuing.  Systems  engineers  create  a  class  structure  to  address  their  packaging  goals. 
They  decide  how  the  parts  of  the  behavioral  model  wUl  be  allocated  among  CoRE  classes. 
They  create  boundary,  mode,  and  term  classes  based  on  their  packaging  goals.  They  define  the 
class  interfaces  and  identify  class  dependencies. 

•  DeUttledBdutmr  Specification.  Systems  engineers  complete  the  dass  definitions  by  completing 
the  spedfication  of  the  controlled  variable  functions  and  timing  constraints  for  each  con¬ 
trolled  variable.  They  refine  the  class  structure  to  be  consistent  with  the  behavioral  model 
needs. 

•  Define  Hardware  Inietface.  Systems  engineers  define  the  system  inputs  and  outputs  and  define 
the  input  (IN)  and  output  (OUT)  relations. 


Figure  5  (from  Figure  6-1  of  Software  Productivity  Consortium  1993)  illustrates  the  five  activities  of 
the  CoRE  process  along  with  their  corresponding  work  products.  Those  work  products  and  activities 
whose  development  is  affected  by  the  use  of  an  RDD-100  system  design  model  are  shaded. 


RgureS.  The  CoRE  Process 


2.2.2  Ck>RE  Behavioral  Model 

The  CoRE  behavioral  model  provides  a  standard  formal  model  for  specifying  the  required  behavior 
of  an  embedded  system.  The  behavioral  model  represents  the  semantics  of  the  requirements 
specification.  Figure  6  illustrates  the  underlying  behavioral  mcxlel  of  CoRE. 
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This  section  is  divided  into  three  subsections,  each  of  which  describes  a  part  of  the  behavioral  model 
that  is  of  particular  interest  for  this  report:  environmental  variables  (Section  2.2.2.1),  input  and  output 
variables  (Section  22.2.2),  and  four-variable  relations  (Section  2.2.2.3). 


Figure  6.  Ibe  CoRE  Software  Bequirements  Behavioral  Model 


2,22.1  En\ironmental  Variables 

Environmental  variables  are  physical  quantities  of  interest  in  the  environment  of  a  system.  For 
otample,  air  pressure  is  of  interest  to  an  automotive  engine-control  system.  There  are  two  kinds  of 
environment^  variables: 

•  Motored  Variables.  Environmental  quantities  the  system  must  track  (e.g.,  the  ambient  air 
pressure). 

•  Controlled  Variables.  Environmental  quantities  the  system  sets  (e.g.,  the  fuel  flow  to  the 
cylinders). 


222.2  Input  and  Output  Variables 

Input  and  output  variables  are  variables  representing  discrete  inputs  or  outputs  of  the  software.  The 
complete  definition  of  an  input  (output)  variable  describes  precisely  how  the  software  reads  from 
(writes  to)  a  device,  including  the  protocol  for  reading  from  (writing  to)  a  device  and  a  mapping 
between  abstract  values  and  the  bit  patterns  read  from  (written  to)  the  device. 
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2J123  Fottf'^riable  Relatioos 

Four-variable  relations  contain  ordered  pairs  of  environmental  variables  and  input  and  output 
variables.  There  are  four  kinds  of  relations  in  the  CoRE  behavioral  model: 

•  NAT.  NAT  specifies  the  external  constraints  on  the  values  that  the  environmental  variables  can 
assume.  These  constraints  are  properties  of  the  environment  that  affect  the  software  but  exist 
independently  of  the  software. 

•  REQ.  REQ  specifies  properties  that  the  ^tem  is  required  to  maintain  between  monitored 
and  controlled  variables.  The  REQ  relation  is  the  fundamental  means  of  spedfying  behavioral 
requirements  with  CoRE. 

•  EV.  IN  expresses  values  taken  on  by  the  monitored  variables  as  a  function  of  bit  settings  or 
other  low-level  hardware  settings  (input  variables). 

•  OUT.  OUT  spedfies  values  of  controlled  variables  as  a  function  of  the  values  of  output 
variables. 

Figure  7  illustrates  how  these  variables  are  related  by  the  four  kinds  of  relations. 


Input  \%riable  Output  Variable 


I^gure  7.  Ibe  CoRE  Four-Variable  Model 

2.23  Core  Class  Model 

The  CoRE  class  model  provides  a  set  of  fadlities  for  packaging  the  information  in  a  CoRE 
specification.  The  class  model  allows  you  to  divide  the  spedfication  into  relatively  independent  parts 
and  to  control  the  relationships  between  parts.  The  class  model  is  not  intended  to  imply  any 
requirements  about  the  behavior  of  the  soft^re. 

The  information  in  the  four-variable  model  is  partitioned  among  a  set  of  CoRE  classes.  A  CoRE  class 
is  a  template  for  defining  a  subdass  or  object  (conversely,  an  object  is  always  an  instance  of  a  class). 
Systems  engineers  determine  sudi  characteristics  as  the  number  of  classes,  what  information  is  hidden 
by  each  class,  and  which  parts  of  the  model  are  allocated  to  the  same  class  based  on  their  overall  goals 
for  the  requirements  structure.  There  are  three  kinds  of  CoRE  classes: 

•  Boundary  Classes.  Contain  the  definitions  of  the  system’s  monitored  and  controlled  variables. 

•  Mode  Classes.  Encapsulate  mode  machine  definitions  and  provide  mode  information. 

•  Torn  Classes.  Provide  any  terms  (named  expressions  of  monitored  variables)  not  provided  by 
the  boundary  and  mode  classes. 
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Core’s  class  model  exists  with  quite  different  motivations  than  those  of  design  and  implementation 
methods.  CoRE  deals  with  objects  and  classes  as  buckets  for  containing  interesting  parts  for  the  sake 
of  designing  the  specification  rather  than  the  system.  Designing  a  specification  with  classes  differs 
from  designing  a  system  for  object-oriented  implementation  in  the  following  ways: 

•  The  Core  class  structure  is  part  of  the  requirements  specification,  intended  to  facilitate 
packaging;  it  is  not  part  of  the  system  itself.  It  may  be  that  a  different  class  structure  will  be 
applied  to  the  system  during  implementation. 

•  Although  Core  recognizes  an  inheritance  from  superclasses,  the  idea  of  class  structure  for 
encapsulating  (hiding)  information  and  the  depends-on  relationship  between  specification 
objects  are  much  more  important. 

The  inheritance  relationship  is  a  dominant  feature  of  the  structure  of  prt^ams  to  be  built  with 
object-oriented  implementation  languages  primarily  because  of  the  overwhelming  importance  of 
reusing  code  from  superclasses.  Code  reuse  and,  consequently,  the  inheritance  relationship  are  not 
^icaUy  critical  concerns  during  requirements  specification. 

The  classes  in  a  CoRE  specification  are  best  viewed  as  "cell  walls"  created  to  contain: 

X 

•  Encapsulated  information  (secrets) 

•  Parts  of  the  system  that  are  likely  to  change,  as  opposed  to  those  prone  to  remain  stable 
23  COMPARING  RDD>100  AND  CoRE 

RDD-100  supports  system  requirements  analysis  and  design,  where  a  system  is  made  up  of  hardware, 
software,  and  people.  CoRE  supports  software  requirements  analysis.  For  CoRE  to  be  applied  to  a 
software  system  that  is  part  of  a  larger  ^tem  spedfied  using  RDD-100,  the  RDD-100  model  must 
(and  does)  contain  all  of  the  information  needed  to  build  a  CoRE  specification.  Of  course,  the  CoRE 
requirements  writer  must  know  which  parts  of  the  RDD-100  model  are  useful  for  CoRE  and  which 
are  not 

The  earliest  activity  in  the  RDD-100  process  consists  of  decomposing  system  requirements 
documents  into  hierarchies  of  individual  system  requirements.  The  subset  of  these  system 
requirements  related  to  the  software  subitem  being  specified  using  CoRE  along  with  any  related 
RDD-100  database  elements  derived  from  them  provides  the  basis  for  a  CoRE  specification. 

RDD-100  encourages  the  systems  engineer  to  define  the  environment  in  which  the  proposed  system 
will  operate.  The  environment  includes  those  external  systems  and  environmental  entities  that  have 
an  effect  upon  the  system  and  those  variables  that  are  transferred  between  the  ^stem  and  the  environ¬ 
ment  or  external  system.  This  information  is  essential  to  a  CoRE  specification,  which  specifies  the 
required  relationships  between  variables  that  are  monitored  by  the  software  system  and  those  that  are 
controlled.  RDD-100  captures  this  information  using  behavior  diagrams  and  provides  automatic 
translation  to  the  context  diagram  format  recognized  by  CoRE. 

CoRE  provides  powerful  techniques  for  nonalgorithmic  expressions.  CoRE’s  focus  is  on  tabular 
mathematical  descriptions  of  actions  as  a  function  of  events,  conditions,  and  modes.  RDD-100  does 
not  currently  support  this  notation;  it  allows  specification  of  behavior  using  flowlike  descriptions  for 
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tuning  and  sequendng  (behavior  diagrams).  RDD-100  was  not  intended  to  and  does  not  provide  the 
tools  necessary  to  build  a  CoRE  software  requirements  specification. 

RDD-100  offers  robust  modeling  features  for  analyzing  a  system  design.  The  system  design  is 
specified  using  a  hierardiy  of  behavior  diagraim.  Making  a  design  analyzable  requires  the  system 
de^gner  to  indude  decisions  related  to  logic,  sequencing,  or  conoirrency  in  the  behavior  diagrams. 
Frmn  the  CoRE  perspective,  these  kinds  of  dedsions  may  be  considered  design  dedsions  that  should 
be  avoided  during  software  requirements  aiudysis.  As  a  result,  a  completed  RDD-100  spedfication, 
composed  via  the  RDD  metho^Iogy,  may  have  more  information  than  is  necessary  to  build  a  CoRE 
specification.  More  precisely,  it  is  likely  that  only  the  highest  level  behavior  diagrams  in  the  RDD-100 
modd's  hierarchy  will  be  needed  for  CoRE. 

In  summary,  an  RDD-100  system  model  does  not  contain  all  of  the  information  that  a  CoRE  software 
requirements  spedfication  contains.  There  is  an  inherent  difference  in  the  level  and  amount  of  detail 
between  system  and  software  spedfications.  The  software  spedfication  contains  requirements  that 
are  derived  from  the  systom  spedficatimi.  A  oomfdete  CoRE  spedfication  carmot  be  automatically 
generated  from  an  RDD-100  spedfication.  However,  RDD-100  is  a  suitable  starting  point  for  CoRE 
because  it  contains  all  of  the  information  needed  to  begin  CoRE.  The  CoRE  requirements  writer  must 
know  udiere  in  an  RDD-100  model  to  find  relevant  pieces  of  information  and  how  to  build  a  CoRE 
specification  from  them.  The  best  use  of  RDD-100  with  CoRE  is  to  build  the  CoRE  spedfication  with 
a  more  ai^ropriate  tool,  such  as  and  to  make  use  of  the  fadlities  RDD-100  provides  for 

transitioning  from  lystem  design  using  RDD-100  to  software  requirements  using  itaaawork  (and 
CoRE). 
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3.  AN  APPROACH  FOR  DERIVING  A  CoRE  MODEL 
FROM  AN  RDD-100  MODEL 

This  section  describes  an  approadi,  inducting  the  process,  guidelines,  and  examines,  for  deriving  a 
Core  software  requirements  model  from  an  RDD400  ^tem  requirements  and  design  model.  The 
activities  involved  in  this  approadi  indude: 

•  Building  the  RDD-100  model  (Section  3.1) 

•  Identifying  CoRE  inputs  in  the  RDD-100  model  (Section  3.2) 

•  Mapping  the  information  contained  in  an  RDD-100  model  to  an  initial  CoRE  spedfication 
(Se^on  33) 

•  Com{deting  the  CoRE  spedfication  (Section  3.4) 

This  set  of  activities  is  not  intended  to  be  strictly  sequential;  iteration  is  ejqiected. 

3.1  BUILDING  TEIE  RDD-100  MODEL 

T)  describe  an  approach  for  deriving  a  CoRE  model  from  an  RDD-100  model,  it  is  necessary  to  make 
some  assumptions  about  what  is  contained  in  the  RDD-100  model.  This  section  describes  the  assumed 
[H’(x:ess  for  developing  a  ^tem  requirements  model  using  RDD-100.  The  intention  is  to  provide  the 
least  number  of  constraints  possible  so  that  the  approadi  is  applicable  to  the  widest  possible  range  of 
established  RDD-100  users. 

The  assumed  process  indudes  a  subset  of  those  activities  described  in  Alford  (n.d.).  The  RDD-100 
model  should  not  be  built  any  differently  than  usual,  but  for  the  purposes  of  CoRE,  it  is  assumed  that 
a  minimal  set  of  activities  has  been  performed.  The  assum^  process  for  developing  a  ^tem 
requirements  model  using  RDD-100  includes: 

•  ^tem  requirements  analysis  (Section  3.1.1) 

•  ^tem  functional  analysis  (Section  3.13) 

•  ifystem  design  (Section  3.1.3) 

Section  3.1.4  offers  some  suggested  tactics  for  building  the  RDD-100  model  for  those  systems 
engineers  who  know  beforehand  that  CoRE  will  be  used  to  spedfy  software  requirements. 

3.L1  RDD-100  System  Requirements  Analysis 

The  RDD-100  system  requirements  analysis  activity  begins  by  identifying  individual  system 
requirements  statements  from  requirements  documents  (e.g.,  a  mission  statement).  Each  sudi 
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requirements  (kxnunent  is  identified  in  the  RDD-100  database  creating  an  associated  element  of 
type  SourG0.  The  RDD-100  requirements  extractor  can  be  used  to  parse  a  textual  document  and  to 
create  a  hierard^  of  individual  system  requirements  in  the  database,  known  as  SystemRequuremwit 
elements.  The  resulting  relationships  between  elements  are: 

•  Doamerits  relationships  are  aeated  between  Source  elements  and  the  S/stomRequrement 
elements  th^  contain. 

•  Inoorpontae  relationships  are  aeated  between  SystemRequIfement  elements  and  their  child 
SystemReqiHnmwit  elements  in  the  hierarchy. 

CrShdtssue  elements  are  aeated  for  recording  tedmical  issues  oitical  to  the  successful  development 
of  the  qrstem.  Documents  relationships  relate  Source  elements  to  CrWcdlssue  elements,  and  TracesTo 
relationships  record  their  traceability  from  SystemRequiremert  elements.  When  critical  issues  are 
resolved,  their  resolutions  are  recorded  in  Decision  elements,  and  TracesTo  relationships  are  used  to 
rdate  tliese  element  pairs.  DecMon  elements  mxy  result  in  the  aeation  of  additional 
SystenUiequiremera  elements,  and  TracesTo  relationships  are  also  used  to  relate  these  element  pairs. 
Documents  relationships  may  also  relate  Source  elements  to  Decision  elements.  Figure  3  illustrates  the 
elements  and  relationships  supporting  the  RDD-100  ^tem  requirements  analysis  activity. 

Fa  the  HAS  Buoy  case  stutty  desaibed  the  Appendix,  there  were  two  Source  elements:  the  HAS  Butty 
problem  statement  (see  Seaion  App.l)  and  a  list  of  requirements  stabilities  and  variabilities  (see  Sec¬ 
tion  App.1.6).  Section  App.2.2  documents  the  hierarc^  of  SystemReqiJrwtert  elements.  Criticailssue 
and  Decision  elements  are  desaibed  in  Section  App.2.4. 

3.L2  RDD-1(M)  System  Functional  Analysis 

In  the  RDD-100  system  frmctional  analysis  activity,  tystems  engineers  develop  a  functional  model  that 
reflects  the  functional  requirements  of  the  system  (Alford  n.d.).  The  goal  is  to  develop  a  functional 
model  that  represents  the  desired  behavior  of  the  system.  During  this  activity,  systems  engineers  will 
define  how  the  system  will  logically  operate  and  provide  a  basis  of  how  the  sJlocated  design  must 
behave.  This  activity  consists  of  identifying  system  subsets  called  ComponentSf  whose  behaviors  are 
spedfied  using  behavior  diagrams. 

Be^  the  RDD-100  system  functional  analysis  activity  Ity  decomposing  the  tystem  into  Components 
as  follows: 

•  Create  a  Component  element  of  type  System  representing  the  entire  spedficadon,  with  the 
name  of  your  tystem  {Components  of  a  particular  type  are  aeated  by  setting  the  Compon&nt 
Type  attribute  of  the  Component  acoordii^y). 

•  Create  Component  elements  of  type  ExtemaiSystem  representing  systems  external  to  your  own 
with  whidi  your  tystem  must  interad. 

•  Create  Component  elements  of  type  Environment  representing  entities  in  the  environment  that 
have  an  effect  on  your  tystem. 

•  Create  Component  elements  of  other  types  (e.g..  Subsystem,  C^i,  etc.)  representing  internal 
parts  of  the  tystem  such  that  all  SystemRequiremert  elements  have  t^n  mapped  to  a 


18 


3.  An  Approach  tor  Pcfwif  Core  i4odellTO««BRDD-100  Model 


Component  dement  (either  directly  the  TracesTo  relationship  or  indirectly  through  the 
functkmal  model). 

l^)ccify  the  behavkxrs  of  these  Components  as  follows: 

•  Specify  the  behavior  of  the  System  Component  element  by  aeating  a  behavior  diagram  (FA/et) 

contains  the  functions  performed  by  all  related  ExtemalSystem,  Erwironment,  and  other 
Con^poneris. 

•  Create  a  HaaContext  relationship  between  the  System  Component  element  and  the  FNet 
dement 

•  Specify  interactions  between  Components  using  dements  of  type  Tim^em,  Discreteltem,  or 
Intet^ce. 

•  Describe  the  precise  behavkn  of  an  individual  Component  element  by  decomposing  and 
allocating  fun^onalify  to  TimeFuncUon  and  IXscr^eFuncUon  elements. 

•  Specify  timipg  requirements  in  the  "duration**  attributes  of  FtmcUons  for  subsequent 
n^eling.  Create  Perfonnanceindex  elements  as  necessary  to  capture  timing  requirements. 

•  Create  additional  CriUcallssue  and  Decision  elements  during  this  activify  as  you  realize  their 
need. 

The  remaining,  lower  level  details  of  the  behavior  diagrams  are  completed  sudi  that  suffident  detail 
is  provided  to  allow  RDD'lOO  to  execute  the  behavior  diagram  using  the  Efynamic  Verification  Factl* 
ify.  These  lower  level  details  are  considered  design  by  CoRE:  although  some  may  imply  constraints 
upon  the  software  requirements,  others  may  not  be  used  during  the  application  of  CoRE. 

Section  App.2.7  of  the  HAS  Buoy  case  study  describes  the  Component  elements  that  were  identified 
and  shows  the  hierardiy  graphicsdly. 

3uL3  RDD-100  System  Design 

^stem  design  is  the  final  activity  of  the  RDD-100  process.  The  RDD-100  system  design  activify 
consists  of  allocating  the  system  behavior  (functionalify)  to  the  fystem  ardiitecture  (Alford  n.d.).  The 
engineer  should  consider  several  allocation  strategies,  which  can  be  evaluated  using  the  Ifynamic 
Verification  Bu:ilify. 

Wystan  design  using  RDD-100  is  performed  Ify  seating  AllocatedTo  relationships  between 
DfscreteFunction  elements  and  Component  elements.  DIscr^eFunction  elements  are  aggregated  to 
reflect  the  behavior  of  the  Component  (i.e.,  show  inputs,  outputs,  and  the  logic  the  Component  is  to 
perform). 

Section  App2.7  identifies  the  AllocatedTo  relationships  that  were  identified  for  the  HAS  Buoy  case 
study. 
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3.1.4  Tactics  That  Support  Core 

This  section  offers  some  suggested  tactics  for  building  the  RDD-100  model  for  those  systems 
engineers  who  know  beforehand  that  CoRE  will  be  used  to  spedfy  software  requirements: 

•  Use  tedmiques  that  allow  you  to  isolate  those  parts  of  the  RDD-100  model  that  are  likely  to 
map  to  Co)^  elements  (i.e.,  those  RDD-100  elements  identified  in  Sections  3.1.1  through 
3.13).  For  examine,  use  naming  conventions  for  identifying  those  RDD-100  elements  that  are 
of  particular  interest  to  CoRE  (e.g.,  Components,  O/screte/rems,  etc.).  In  the  HAS  Buoy  exam¬ 
ine,  the  names  of  RDD-100  elements  of  inter^t  to  CoRE  were  capitalized,  vdiile  those  that 
were  not  of  interest  were  stated  in  lower  case. 

•  When  using  RDD-100  and  creating  elements  that  will  later  become  part  of  a  CoRE 
specification  (e.g.,  monitored  variables,  terms,  etc.),  make  sure  that  these  elements  are  not 
used  in  ways  contrary  to  the  use  of  CoRE.  For  example,  perform  modeled  manipulations  on 
Discreteltem  that  you  expect  to  become  monitored  variaUes  via  a  series  of  intermediate  steps 
so  that  you  can  represent  these  mampulations  as  CoRE  terms,  and  store  them  in  relevant 
problem  classes. 

•  Make  the  behavior  diagram  corresponding  to  the  CoRE  context  diagram  executable,  and 
avoid  any  more  detail  than  is  necessary  to  do  so.  RDD-lOO's  DVF  is  a  useful  tool  for  evaluating 
a  system  design.  However,  DVF  leads  you  to  specify  algorithmic  Filets,  which  are  likely  to 
provide  more  detail  than  is  necessary  for  CoRE. 

•  When  using  the  element  editor,  specify  as  mudi  CoRE-relevant  Information  as  possible  when 
recording  the  textual  templates  assodated  with  elements  (e.g.,  always  spedfy  the  Description 
attribute  of  elements).  Also,  make  good  use  of  the  consistency  cheddng,  particularly  the 
^Tundamental”  and  "system  engineering”  levels  of  checking. 

An  RDD-100  model  is  generally  useful  for  CoRE,  and  the  remainder  of  this  report  is  based  on  the 
assumption  that  the  systems  engineer  using  RDD-100  was  not  aware  of  the  intent  to  subsequently 
create  a  CoRE  spedfication.  However,  if  the  systems  engineer  using  RDD-100  is  aware  of  a  subse¬ 
quent  CoRE  spe^cation,  the  tactics  described  in  this  section  should  fadlitate  transition  from  RDD 
toCoRR 

3.2  IDENTIFYING  CoRE  INPUTS  IN  THE  RDD-100  MODEL 

The  RDD-100  system  model  should  contain  all  of  the  information  needed  to  begin  building  a  CoRE 
software  specification.  In  fact,  the  RDD-100  model  is  likely  to  contain  more  information  than  is  need¬ 
ed  for  Core.  In  any  case,  the  systems  engineer  should  verify  that  the  RDD-100  model  contains  the 
necessary  inputs  to  CoRE. 

As  Figure  5  shows,  the  necessary  inputs  to  CoRE  are:  mission  statement,  system  model,  system 
requirements  spedfication,  system  component  interface  specifications,  and  requirements 
information  relatiiig  to  system  performance.  This  section  is  divided  into  five  subsections  desoibing 
how  eadi  of  these  inputs  might  be  recorded  in  an  RDD-100  model.  Ihble  1  summarizes  the  mapping 
from  RDD-100  sdiema  elements  to  CoRE  inputs  and  identifies  \riiere  to  locate  candidate  RDD-100 
schema  elements  in  the  RDD-100  ^tem  Engineering  Notebook  (SEN). 
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liUe  1.  Core  loputs  in  the  RDD-100  Model 


CoRElBIMts 

Candidate  RDD-IM 
Schema  Element(s) 

Where  Found  (SEN  Chapter) 

Mission  statement 

Source 

External  to  RDD-100 — input  documents 

System  model 

FNet  (system  context  diagram) 
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FA/et;  context  diagram  is  Figure  1-1 
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Chapter  2,  “System-Level  Operating 
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Tbneltem 

Chapter  10,  “Interfaces  Between  Ounpo- 
nents” 

Requirements  information 
relating  to  system 
performance 

PeiformenoelndeK 

Chapter  7,  “Performance  Indices” 

3JL1  Mission  Statement 


The  mission  statement  is  a  high-level  description  of  system  requirements.  The  CoRE  requirements 
writer  should  look  at  RDD-100  elements  of  type  Swrco  to  find  the  mission  statement. 

For  the  HAS  Buoy  case  study,  the  equivalent  of  the  mission  statement  was  the  HAS  Ada-based  Design 
.^jproadi  for  Real-Ume  ^tems  (ADARTS*)  Problem  Statement  in  Section  .^>p.l,  \i1iidi  was 
i^tified  in  the  RDD-100  database  by  a  Source  element. 

3^  Stsiem  Model 

The  ^em  model  is  a  functional  desoiption  of  the  behavior  of  the  proposed  system.  The  CoRE 
requirements  writer  should  look  at  the  RDD-100  behavior  diagram  (FN^)  that  models  the  behavior 
of  the  entire  system  to  find  the  ^tem  model.  In  the  RDD-100  model,  a  Componera  element  of  type 
System,  named  approfuiately,  should  be  related  to  an  FiVef  by  a  HasCortact  relationship.  This  FNet 
modds  the  behavior  of  the  entire  system. 

Figure  8  shows  the  system  model  for  the  HAS  Buoy  case  study.  It  is  the  behavioral  model  representing 
the5|iif<em  Con^nment  element. 

3^  Ststem  Requirements  SpBCEFicAnoN 

Tbe  system  requirements  spedfication  is  a  detailed  description  of  system  requirements.  Hie  CoRE 
requirements  writer  should  look  at  the  RDD-100  hierarchy  of  SystemRequirement  elements  to  find  the 
requirements  that  make  up  the  system  requirements  specification.  RDD-lOO’s  Report  Writer 
provides  the  capability  to  automatically  generate  reports,  such  as  the  tystem  requirements 
spedfication,  using  a  variety  of  templates,  induding  MIL-STD-490A,  DOD-STD-2167A,  or 
user-defined  spedfications. 

The  hierardty  of  SystemRequirement  elements  (see  Section  ^p.2.2)  or  the  entire 
RDD-lOO-generated  SEN  (see  Section  App.2)  could  have  served  as  the  system  requirements 
qiedficatimi  for  the  HAS  Buoy  case  stucty. 
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3JL4  SlISilM  Ck>MPCWBNT  iNIERFACE  SPECOnCAnONS 

S^ttem  omnponent  inteiface  specifications  describe  the  interfaces  between  the  subsystems  in  a  system 
and  between  the  ^stem  and  its  environment.  The  CoRE  requirements  writer  should  look  at  RDD-100 
Tftnaltam,  DbcfaMam,  ^mUnk,  and  Intertace  elements  to  find  system  component  interface  spedfica- 
fions.  (X  particular  interest  are  those  elements  that  are  shared  1:^  the  System  Con^x>nent  element  (see 
Section  3.22)  and  other  Component  elements. 

Sections  App.26  and  App2.8  of  the  HAS  Buoy  case  study  identify  Timeltem,  Discr^eltem,  ItemUnk, 
and  Ma/ktce  elements  ttot  may  be  induded  in  the  ^tem  compcment  interface  spedfication. 

3JL5  RBQUlREME^rIs  iHPORMiiiiON  REiAtim  TO  System  Perfor^^ 

Requirements  information  relating  to  system  performatKe  fypicalfy  specify  end-to>end  system  timing 
requirements.  The  CoRE  requirements  writer  should  look  at  RDD-100  Performancelndex  elements 
to  find  requirements  information  related  to  system  performance.  However,  during  subsequent  CoRE 
aotivkies,  file  requirements  likely  to  identify  additiooal  timing  and  accurate  requirements  (e.g.,  for 
REQ  relations)  are  not  and  should  not  be  containai  in  the  RDD-100  model. 

Section  ^p.2J  identifies  the  Perfonmncelndax  elements  for  the  HAS  Buoy  case  study. 

33  MAPPING  THE  RDD-100  MODEL  TO  AN  INITIAL  CoRE  SPECinCATION 

This  section  describes  how  elements  of  an  RDD-100  ^tem  design  model  map  to  a  CoRE  software 
requirements  spedfication.  Based  on  the  RDD-100  aj^roadi  desoibed  in  Section  3.1,  it  describes 
what  elements  of  the  CoRE  model  are  most  likely  to  be  found  in  the  RDD-100  model. 

As  Figure  5  shows,  the  first  CoRE  activity.  Identify  Environmental  Variables,  indudes  development 
ofthefoUomng:CoR£information  model,  candidate  environmental  variables,  likelychanges  list,  and 
environmental  constraints  spedfication  (NAGT).  This  section  is  divided  into  four  subsections,  each  of 
wddcfa  describes  what  parts  of  an  RDD-100  model  contain  the  information  needed  to  build  one  of 
those  products.  Thble  2  summarizes  the  mapping  from  RDD-100  schema  elements  to  CoRE  products. 

lliUe2.  CoRE  Products  in  the  RDD-100  Model 
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Environmental  constraints 
specification  (NAT) 
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33.1  Core  iNFORMAnoN  Model 

The  Core  information  model  captures  physical  entities  and  the  associations  between  them  that  may 
be  relevant  to  the  software.  An  RDD-100  System  Component  element  maps  to  the  system  entity  in  the 
Core  information  model.  Other  kinds  of  Component  elements,  especially  ExternalSystem  and 
Enfbonment  Component  elements,  are  candidates  for  additioiud  entities  in  the  CoRE  information 
noodel.  Mterface  elements  that  represent  connections  between  those  Components  map  to  relationships 
between  the  corresponding  entities  in  the  CoRE  information  model.  Discr^eltem  and  Timeltem 
elements  that  are  communicated  by  those  Componerris  map  to  attributes  of  entities. 

Sectitm  contains  the  CoRE  information  model  for  the  HAS  Buoy  case  stuify. 

333  CANiHiMiEENvmoNMEOTAL  Variables 

Candidale  envirtmioeatal  variables  (Le.,  monitored  and  controlled  variaUes)  can  be  derived  from: 

•  The  likely  changes  list  (see  Section  333) 

•  De^nces,  environmental  entities,  or  otternal  hardware  or  software  that  has  an  effect  on  your 
system  (see  Section  33.1) 

Brom  the  RDD-100  perspective,  candidate  environmental  variables  can  be  derived  from  any  of  the 
followmg  RDD-100  elements:  Irterfsce,  Component,  ExternalSystem,  D/screte/tem,  Timeltwn, 
Crtlcallssue,  Decision,  or  SystemParameter. 

Section  App3.1  identifies  candidate  environmental  variables  for  the  HAS  Buoy  case  stutty. 

333  iJKELY  Changes  List 

The  likely  dianges  list  identifies  likely  dianges  in  system  requirements.  Likely  changes  should  be 
indicated  1^  the  existence  of  CrIOcallssue,  Dedsion,  or  SystemParameter  elements  in  the  RDD-100 
model.  If  ai^  of  these  elements  odst  in  the  RDD-100  model,  apply  the  CoRE  criteria  to  determine 
whether  the  element  indicates  the  need  for  an  addition  to  the  likely  changes  list. 

Section  App.1.6  provides  a  list  of  likely  changes  for  the  HAS  Buoy  case  study.  Section  App.2.4 
identifies  related  RDD-100  Critlcallssue  and  Decision  elements  (there  were  no  SystemParamder 
elements). 

33.4  Environmental  Constraints  SPECincAnoN  (NAT) 

IBndronmental  constraints  are  information  about  environmental  variables  related  to  possible  values 
and  interpretation  of  these  values,  e.g.,  the  type  of  the  quanti^,  possible  range  of  values,  and  maxi¬ 
mum  rate  of  diange.  Environmental  constraints  may  be  indicated  by  the  existence  of  Constraint  ele¬ 
ments  in  the  RDD-100  model.  Environmental  constraints  on  the  set  of  possible  values  that  an 
environmoital  variable  can  take  on  are  recorded  by  the  NAT  relation. 

The  HAS  Buoy  case  study  does  not  provide  any  examples  of  NAT  relations  derived  from  Constraint 
elements. 
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3.4  COMPLETING  THE  CoRE  SPECIFICATION 

This  section  describes  how  the  remaining  parts  of  a  CoRE  spedfication  s^e  affected  by  the  use  of 
RDD-100  after  mi^ping  the  RDD-100  model  to  an  initial  Co^  spedfication  as  describ^  in  Section 
33.  In  particular,  it  desoibes,  from  the  CoRE  perspective,  where  to  find  the  necessary  information 
to  compete  the  CoRE  specification  when  the  RDD-100  is  used  as  the  front  end  to  CoRE.  Those  parts 
of  a  CoRE  spedfication  that  are  unaffected  by  the  use  of  RDD-100  are  not  described  here. 

As  Figure  S  shows,  the  following  remaining  CoRE  products  are  affected  by  the  use  of  RDD-100  for 
systems  ei^eering:  context  diagram  (including  monitored  and  controlled  variables),  input  and  out¬ 
put  variable  definitions,  and  timing  and  accuracy  constraints.  This  section  is  divided  into  subsections 
that  describe  uhat  parts  of  an  RDD-100  model  contain  the  information  needed  to  build  one  of  those 
{voducts. 

3.4.1  Context  Diagram 

The  CoRE  context  diagram  captures  the  interaction  of  a  software  system  within  its  enviroiunent.  The 
CoRE  context  dia^am  represents  a  subset  of  the  environment  that  might  be  represented  in  a  context 
diagram  frn'  an  entire  ^tem,  such  as  for  the  system  model  des^ibed  in  Section  3.2.2.  In  some  cases, 
however,  the  two  context  diagrams  may  be  equivalent  in  scope,  such  as  in  the  HAS  Buoy  case  study, 
as  shown  m  Section  App.3.2.1. 

The  CoRE  context  diagram  includes  a  system  transformation  (Section  3.4.1.1),  terminators  (Section 
3.4.13),  and  monitored  and  controlled  variables  (Section  3.4.1.3). 

34.1.1  System  llraiisfonnaUon 

The  ^tem  transformation  on  the  context  diagram  is  derived  from  the  system  entity  in  the  CoRE 
information  model,  which  was  derived  from  an  RDD-100  System  Component,  named  appropriately 
(see  Section  33.1).  The  name  of  the  system  transformation  may  be  inherited  from  the  corresponding 
RDD-100  element. 

34.13  Ibrminators 

Tbrminators  on  a  CoRE  context  diagram  represent  boundary  classes.  Boundary  classes: 

•  Represent  information  about  the  environment  that  is  relevant  to  specifying  the  behavior  of  the 
software 

•  Require  external  resources  (devices  or  external  software  subtystems)  to  acquire  or  influence 
the  information 

The  set  of  boundary  classes  is  derived  from  the  likely  changes  list  and  the  CoRE  information  model 
as  described  in  Section  33.1,  which  are  based  on  corresponding  Component,  Criticallssue,  Decision,  or 
SystwiParam^er  elements  in  the  RDD-100  model. 


34.13  Monitored  and  Controlled  Variables 

CoRE  environmental  variables  are  physical  quantities  of  interest  to  the  software.  Monitored  variables 
are  environmental  variables  measur^  by  the  software.  Controlled  variables  are  controlled  by  the 
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software.  Monitored  and  controlled  variables  zppeu  on  the  context  diagram  as  arrows  between  the 
^tem  transformation  and  terminators  (boundary  classes). 

Candidate  environmental  variables  can  be  found  in  the  CoRE  information  model  (see  Section  33.1). 
lypically,  environmental  variables  will  appear  as  attributes  of  entities  in  the  CoRE  information  mod¬ 
el.  Specifically,  w^en  RDD-100  is  used,  monitored  variable  candidates  can  be  derived  from  RDD-100 
D/^crete/tom  and  Timeltem  elements  whose  Source  is  a  Component  with  a  corresponding  entity  in  the 
Core  information  model.  Controlled  variable  candidates  can  be  derived  from  RDD-100  Discr^eUem 
and  Timeltem  elements  whose  Thrgef  is  a  Component  with  a  corresponding  entity  in  the  CoRE  informa¬ 
tion  model.  CoRE  recommends  using  the  environmental  constraints  (see  Section  33.4)  and  the  likely 
diai^es  list  (see  Section  333)  as  a  guide  in  identifying  and  specifying  the  definitions  of  monitored 
and  control!^  variables. 

3.4.2  Input  AND  Output  Variable  DEFiNinoNS 

IN  relations  record  how  the  software  can  use  input  variables  to  approximate  the  values  of  monitored 
variables.  OUT  relations  record  how  the  software  can  use  output  variables  to  set  the  values  of  con¬ 
trolled  variables.  Input  variables  are  descriptions  of  pbysical  interfaces  to  the  environment  that  allow 
software  to  determine  the  values  of  monitored  variables.  Output  variables  are  descriptions  of  pl^ical 
interfaces  to  the  environment  that  allow  software  to  set  the  values  of  controlled  variables. 

Section  33.4  spedfies  that  system  component  interface  spedfications  should  be  contained  1^ 
'Hmettem,  Discr^eltem,  or  Irtterteoe  elements  that  are  shared  by  the  System  Component  element  and 
other  Component  elements,  particularly  those  of  fype  ExtemalSystem  or  EnvIronmerU.  Those 
Cwnpomnt  elements  of  type  ExtemalSystem  or  EmlronnmU,  whose  behavior  should  be  specified  using 
behavior  diagrams,  are  useful  in  spedfying  IN  and  OUT  relations.  The  Timeltem,  Dlscreteltem, 
ItemUnk,  or  Intwfaoe  elements  referred  to  Section  33.4  are  useful  in  spedfying  the  corresponding 
input  and  output  variables. 

IN  and  OUT  relations  for  the  HAS  Buoy  case  shufy  are  contained  in  Sections  i^>p33.4.1  and 
App33.43,  respectively. 

3.43  Timing  AND  Accuracy  Ck>NSTRAiNTS 

CoRE  timing  and  accuracy  constraints  define  the  allowable  tolerance  in  terms  of  timing  and  accuracy 
assodated  with  CoRE’s  mathematical  relations.  These  constraints,  which  are  sometimes  based  on 
requirements  information  relating  to  ^tem  performance  (see  Section  3.23),  maybe  derived  from 
Performanoelncl&c  elements  when  using  RDD-100  for  system  design.  In  other  cases,  timing  and 
accuracy  constraints  will  be  determined  later  in  the  CoRE  process  after  the  RDD-100  model  has  been 
completed. 

Section  App.33.6  identifies  the  timing  and  accuracy  constraints  for  the  HAS  Buoy  case  study  thatwere 
captured  in  the  RDD-100  model. 
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4.  EXTENDING  THE  RDD-100  SCHEMA  TO 

SUPPORT  Core 


The  RDD-100  Extender  (Ascent  Logic  Corporation  1991a)  allows  systems  engineers  to  tailor  the 
underlying  database  schema  of  RDD-100  for  their  own  needs.  Extending  the  schema  such  that 
CoRE-specific  elements,  such  as  monitored  variables  and  input  variables,  are  recognized  by 
RDD-100  will  allow  ^ems  engineers  to  specify  designs  that  are  more  consistent  with  the  needs  of 
Core. 

Tkble  3  identifies  those  elements  and  relationships  systems  engineers  might  add  to  the  RDD-100 
database  sdiema  in  support  of  CoRE  as  Figure  7  shows.  Making  these  additions  to  the  standard, 
underlying  database  schema  of  RDD-100  allows  it  to  recognize  CoRE  concepts  and,  therefore, 
facilitates  mapping  from  an  RDD-100  model  to  a  CoRE  model. 

IkbleS.  Extended  Schema  for  CoRE 


Source  Element 

Relationship 

Tsiget  Element 

Controlled  Variable 

Is_A_Kind_Of 

Environmental  Variable 

NAT  Inverse 

Monitored  Variable 

REQ  Inverse 

Monitored  Variable 

OUT  Inverse 

Output  Variable 

Monitored  VariaUe 

Is_A_Kind_Of 

Environmental  Variable 

NAT 

Controlled  Variable 

REQ 

ControUed  VariaUe 

IN 

Input  Variable 

Input  Wriable 

Is_A_Kind_Of 

Input/Output  Variable 

IN  Inverse 

Monitored  Variable 

Ouq>ut  Variable 

Is_A_Kind_Of 

Input/Output  Variable 

OUT 

Controlled  Variable 

In  experimentation  with  the  RDD-100  Extender  for  the  purpose  of  supporting  CoRE,  the  Consortium 
conduded  that  the  benefit  obtained  by  modifying  the  RDD  -100  database  schema  for  CoRE  use  is  mar¬ 
ginal.  By  adding  CoRE-spedfic  elements  to  the  schema,  new  elements  are  created  that  parallel  the 
purposes  of  CTSting  elements.  The  benefit  obtained  is  the  capability  to  refer  to  RDD-100  elements 
by  the  names  of  their  equivalent  CoRE  elements  (e.g.,  monitored  variable,  input  variable). 

Ascent  Logic  Corporation  has  delivered  Release  4.0  of  RDD-100  (this  report  assumes  version  3.0.2 
of  PDD-100),  which  contains  Real  World  and  Abstract  Object  Editors  that  obviate  the  need  to  extend 
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the  database  schema  for  CoRE  using  the  Extender.  The  same  benefits  provided  by  the  Extender  can 
be  obtained  using  the  Object  Editors  of  Release  4.0  of  RDD-100  without  the  drav^adts.  The  C%ject 
Editors  allow  systems  engineers  to  overlay  a  modified  schema  onto  the  predefined  RDD-100  schema 
so  that  database  elements  are  not  replicated  for  the  modified  sdiema.  Iherefore,  Ihble  3  is  included 
in  this  report  because  it  useful  for  identifying  the  objects  and  relations  that  might  be  added  to  the  sdie- 
ma  using  the  Object  Editors.  In  a  future  version  of  this  report,  this  section  will  describe  in  detail  the 
use  of  the  Real  World  and  Abstract  Object  Editors  instead  of  the  Extender. 
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This  section  describes  a  CoRE-spedfic  report  that  can  be  automatically  generated  by  RDD-100  to 
simplify  the  process  of  building  an  initial  ^RE  specification  from  an  RDD-100  model.  Generating 
such  a  report  requires  that  systems  engineers  use  RDD-lOO's  Report  Writer  (Ascent  Logic 
Corporation  1992b)  to  define  the  contents  of  the  report. 

RDD-lOO’s  Report  WHter  provides  templates  ready  for  use,  including  the  following  reports:  SEN, 
data  dictionary,  component  interface,  requirements  allocation,  requirements  traceability,  and 
2167A-compliant  reports  (Interface  Requirements  Specification,  System/Segment  Specification, 
System/Segment  Design  Document,  and,  soon,  the  Software  Requirements  Spedfication). 

The  predefined  report  that  is  most  helpful  to  a  CoRE  analyst  is  the  SEN  (Ascent  Logic  Corporation, 
1991b).  Section  5.1  describes  the  contents  of  the  SEN.  Section  S.2  describes  various  options  for 
generating  a  CoRE-spedfic  report. 

5.1  THE  RDD-100  SYSTEM  ENGINEERING  NOTEBOOK 

This  section  describes  the  RDD-100  SEN.  For  each  section  of  the  SEN,  there  is  a  corresponding 
subsection  containing  a  short  discussion  of  its  contents  and  applicability  to  CoRE. 

5.1.1  System  Top-Level  DEscRipnoN 

This  section  is  very  useful  to  CoRE:  it  describes  a  high-level  view  (a  TimeFun^on)  of  the  ^tem  and 
identifies  the  major  Components  from  which  the  system  is  built.  It  also  identifies  all  external  interfaces, 
performance  requirements,  sources  of  system  requirements,  etc.  related  to  the  high-level  view  of  the 
^tem.  Finally,  it  contains  the  behavior  diagram  illustrating  system  fimctionalify  from  the  highest 
level  This  betovior  diagram  is  very  useful  in  mapping  to  a  CoRE  context  diagram. 

5.1.2  System-Level  ("ORiGiNAriN^)  Requirements 

This  section  contains  the  hierarchy  of  system  requirements  in  alphabetical  order,  induding 
identification  of  relationships  between  them  and  other  RDD-100  database  elements.  These  ^tem 
requirements  are  useful  to  many  CoRE  activities. 

5.U  Design  Constraints 

This  section  identifies  RDD-100  Comtrwnt  elements  and  their  relationships  to  other  RDD-100 
database  elements.  These  Constraints  are  useful  in  identifying  CoRE  NAT  relations. 

5.1.4  Issues  &  Decisions 

This  section  identifies  RDD-100  CriUcailssue  and  Decision  elements,  which  are  important  to  CoRE 
when  identifying  likely  changes  and  candidate  environmental  variables. 
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5.13  HnouitciiiCAL  Function  List 

This  section  identifies  the  RDD-100  TlmeFun^om  that  have  been  decomposed  into  lower  level 
TlmaFuncthns  or  DiscreteFunctions  (exdudiqg  those  that  are  performed  ComponoTts).  These 
functions  general^  represent  a  lower  level  of  detail  than  is  necessary  for  CoRE  and,  therefore,  are 
not  likely  to  be  of  interest  to  CoRE.  Section  5.1.6  describes  the  details  of  these  functions. 

5.1.6  Syshm  Functional  Behavior  DEsaaprK>N 

This  section  contains  the  behavior  diagrams  for  the  RDD-100  TimeFuncaons  identified  in 
Section  5.13.  These  functions  generally  represent  a  lower  level  of  detail  than  is  necessary  for  CoRE 
and,  therefore,  are  not  likely  to  be  of  interest  to  CoRE. 

5.1.7  Performance  Indices 

This  section  describes  the  Performancelndex  elements  that  appear  in  the  RDD-100  database,  whidi 
are  of  interest  to  CoRE  when  specifying  timing  and  accuracy  constraints. 

5.13  Item  DicnoNARY 

This  section  describes  each  Timelt&n  and  Dlscniettem  in  the  RDD-100  database.  Timeltem  and 
DlscntBltem  elements  are  important  to  the  CoRE  practitioner  when  spedfying  the  CoRE  information 
model,  monitored  and  controlled  variables,  and  input  and  output  variable  definitions. 

5.L9  Components 

This  section  of  the  SEN  describes  the  characteristics  of  Components  in  the  RDD-100  database,  whidi 
are  important  throughout  the  CoRE  process.  This  section  illustrates  the  hierardiy  of  system 
Components.  This  hierarchy  is  useful  in  understanding  the  strudure  of  the  RDD-100  model  but  is  not 
required  CoRE. 

5.1.10  Interfaces  Between  Components 

This  section  describes  the  interfaces  between  Component  elements,  including  elements  of  fypes 
Timeltwn,  Dlscr^eltem,  Intertaco,  and  ItemUnk.  This  information  is  important  to  the  CoRE  practitioner 
when  spedfying  the  CoRE  information  model,  monitored  and  controlled  variables,  and  input  and 
output  variable  definitions. 

5.1.11  System  "OperationaE’ Parameters 

This  section  describes  the  Sy^emParam^er  elements  that  appear  in  the  RDD-100  database,  whidi 
may  be  of  interest  to  CoRE  when  identifying  candidate  environmental  variables  and  likely  changes. 
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5.  Gencnning  a  CoRE  Report  From  RDD-100 


5^  A  CoRE-SPECIFIC  REPORT 

There  are  two  ways  to  generate  CoRE-spedfic  reports  using  RDD-lOO’s  Report  Writer: 

•  Predefined  RDD-100  reports  can  be  modified  after  being  generated  using  a  text  editor. 

•  The  contents  of  jn'edefined  RDD-100  reports  are  specified  using  hierarchies  of  behavior 
diagrams,  identified  by  ReporfNet  elements  in  the  RDD-100  database.  Systems  engineers  can 
add  or  delete  ReporWet  elements  or  modify  the  behavior  diagrams  that  define  ReportNets  so 
that  the  Report  Witer  produces  a  report  desaibing  those  database  elements  of  interest  to 
them. 

IWo  ways  to  modify  predefined  RDD-100  reports  to  generate  CoRE  specific  reports  using  the  Report 
WHter  arc: 

•  Begin  with  the  predefined  RDD-100  Sl^: 

—  Modify  the  headings  of  individual  sections  to  indicate  the  potential  for  mapping  from 
RDD-100  elements  to  CoRE  elements  (e.g.,  modify  section  headings  for  the  sections 
containing  ExtemeJS/stem  and  Environment  Components  to  indicate  the  potential  for 
mapping  to  CoRE  environmental  variables). 

-  Remove  those  sections  that  are  not  of  interest  to  CoRE  (i.e.,  the  sections  containing 
the  Hierardiical  Function  List  and  System  Functional  Behavior  Specification). 

•  If  anRDD-100  schema  modification  has  beenmadeto  support  CoRE(see  Section  4),  a  special 
CoRE  report  could  be  generated  that  represents  all  information  assigned  to  CoR&spedfic 
schema  elements,  lb  do  this,  you  could  begin  with  the  ReportfMs  and  behavior  diagrams  used 
1^  the  Report  Writer  that  spedfy  a  similar  predefined  report  and  modify  them  such  that  thQr 
specify  a  report  containing  CoRE-spedfic  schema  elements. 

The  best  approadi  to  generating  a  CoRE-spedfic  report  using  RDD-lOO’s  Report  Writer  for  spedfic 
needs  depends  on  the  amount  of  time  systems  engineers  are  willing  to  invest  and  their  expected  pay¬ 
back  in  terms  of  the  amount  of  time  they  expect  to  save  using  the  Report  Writer,  ^tems  engineers 
must  trade  off  these  parameters  to  determine  whidi  of  the  above  approaches  best  suits  their  needs. 
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6.  USmG  THE  RDD400  BWDGE  TO  TEAMW9M: 


Ascent  Logic  provides  a  bridge  that  allows  ^tems  engineers  to  translate  RDD-lOO  behavior 
diagrams  to  ttMoavork  context  diagrams,  data  flow/control  flow  diagrams,  and  data  dictionary  entries. 
Cadre’s  tumwak  (Cadre  Ibchnologies,  Inc.  1990)  can  be  used  to  develop  CoRE  work  products, 
although  it  does  not  currently  support  CoRE  directly.  If  ^tems  engineers  are  using  itamwork  to 
record  a  CoRE  spedfication.  RDD-lOO’s  bridge  to  ttamwmk  can  {vovide  a  head  start  in  building  their 
Core  spedfication.  Some  RDD-lOO  elements  can  be  automatit^ly  translated  to  teamwork  objects 
that  are  useful  when  building  a  CoRE  spedfication 

Section  6.1  provides  an  overview  of  how  the  RDD-lOO  bridge  to  teamwork  works.  Section  6.2  provides 
an  overview  of  how  teamwork  can  be  used  to  sui^rt  CoRE.  Section  63  describes  how  to  use  the 
RDD-lOO  bridge  to  Cadre’s  teamwork/RT  tool  to  support  the  CoRE  method. 

6.1  THE  RDD-lOO  BRIDGE  TO  TEAMWORK 

Ascent  Logic  Corporation  (1993b)  describes  the  facility  that  allows  tystems  engineers  to  translate 
RDD-lOO  behavior  diagrams  to  teamwork  context  diagrams,  data  flow/control  flow  diagrams,  and 
data  dictionary  entries.  This  bridge  automates  the  transfer  of  certain  elements  from  an  RDD-lOO  da¬ 
tabase  to  the  teamwork  database  Ity  automatically  generating  CASE  Data  Interdiange  Format 
(CDIF)  files  from  the  RDD-lOO  model.  CDIF  files  can  be  loaded  into  the  teamwork  database  using 
the  tv^_put  command,  which  is  part  of  teamwork’s  standard  tool  kit  (Cadre  Ibcfanologies,  Inc.  1990). 

The  mapping  from  RDD-lOO  elements  to  teamwork  objects  is  imi^emented  according  to  the  mapping 
shown  in  Ikble  4.  The  automated  mapping  to  teamwodk  assumes  that  the  system  design  is  developed 
using  RDD-lOO  behavior  diagrams  that  adhere  to  some  constraints  defined  in  Ascent  L^c 
Corporation  (1993b,  2-4). 

Ikble  4.  RDD-lOO  Elements  Mapping  to  Teamwork 


RDD  Element 

Tkamimrk  Object 

System 

Model 

Component 

Model 

TImeFunction 

Process  BnbUe  or  Ibrminator 

tXscreteFunction 

P-^)ec  (process  specification) 

Ttm^tem 

Data  Flow  or  Control  Flow 

Discret^em 

Data  Flow  or  Contrd  Flow 

DataSUxe 

Data  Store 

Note  that  onty  a  subset  of  the  elements  supported  by  RDD-lOO  map  to  teamwork  objects.  Also,  there 
is  no  mapfnng  to  teamwork  control  specifications,  induding:  state-transition  diagrams,  state-event 
matrices,  process  activation  tables,  and  dedsion  tables. 


Data  dictionary  entries  are  also  generated  for  each  generated  tt»mw<xk  data  flow,  control  flow,  and 
data  st<Mre.  AsMnt  Logic  Corporation  (1993b,  2-S)  describes  the  contents  oi  the  generated  data 
dictkmary  entries  as  follows: 


•  Data  dictkmary  entries  for  flows  mapped  from  RDD-100  r/meftems  list  all  items  in  the 
nmitem's  current  decomposition. 

•  The  Description  attribute  of  RDD-100  elements  is  included  in  the  comments  section  of  data 
dictionaiy  entries.  All  other  fllled-in  attributes  of  those  elements  are  listed  as  itamworic 
extended  attributes  (i.e.,  at  the  end  of  the  data  dictionary  entry  following  a  dashed  line). 

^  USING  TEAMIf^OJU:  WITH  Core 

Mudi  of  the  information  in  a  CoRE  specification  can  be  recorded  in  teamMvirfc  in  a  straightforward 
manner.  TeaaatrarA:  can  grafriiicaily  record  much  of  the  information  that  specifies  CoRE  functional 
requirements  using  teaan«orfe*s  dedsion  tables  and  state  transition  diagrams.  The  rest  of  the  CoRE 
sp^ification  can  be  recorded  as  text  in  itamwotk^i  data  dictionary. 

Users  can  capture  CoRE  specifications  in  teamwork  because  CoRE  was  designed  to  use  notations  and 
formalisms  that  are  common  to  available  tools  (e.g.,  data  flow/control  flow  diagrams,  finite  state  ma- 
diines,  etc.).  Because  CoRE  departs  from  some  conventions  assumed  by  teamivorfc,  the  tool  does  not 
support  CoRE  as  completely  as  it  suf^rts  real-time  structured  analysis.  In  particular,  the  chedcs  pro- 
vid^  l^teanitvorii:  are  not  useful  to  the  CoRE  user,  and  some  of  the  CoRE  specification  is  recorded 
as  uninterpreted  text. 

The  mapping  from  CoRE  elements  to  tcamwoh^  objects  is  shown  in  Ihble  5. 

IhUe  5.  TeammvAi’s  Support  for  CoRE  Elements 


1  CoREEkaents 

Teamimrlt  Objects 

Information  model 

Entity 

Entity  in  entity  relationshty  diagram 

Relationship 

Relation  in  entity  relationshq)  diagram 

Attribute 

Defined  in  data  dictionary  entry  for  dass 

Boundary  dass 

I^ocess  bubUe  in  data  flow  diagram 

Mode  dass  control  bar  in  data  flow  diagram 

Class  interfiioe . 

Control  flows  from  process  bubUes  or  from 
control  bars  that  represent  mode  dasses 

Enviromnental  variaUe 

Monitored  variaUe 

Data  flow  from  terminator  on  context  diagram 

Data  dictionaiy  entry 

ControOed  variaUe 

Data  flow  to  terminator  on  context  diagram 

Data  dictionary  entry 

Iiipat/ontpnt  variate 

Input  variaUe 

Data  dictionary  entry 

Output  variaUe 

Data  dictionary  entry 

Fonr-variaUe  relations 

REQ  function 

Control  bar  in  data  flow  diagram 

Decision  taUe 

6.UiiiigtlieRDD-100Bridgett>Tt>«»iarfc 


Ikble  5,  continued 


CrftEEhm— ia 

‘Rantwerk  Okjects 

NAT  relation* 

Ifext  q)edfication  in  data  dictionaiy  entry  for 
oontrdkd  variabte 

INielatioa* 

Text  qiecificatuin  in  data  dictionary  entry  for 
input  variable 

OUT  relation* 

Ibxt  qiedfication  in  data  dictionaiy  entiy  for 
output  variaUe 

ModecfauB 

Modedaas 

Control  bar  in  data  flow  diagram 

State  transition  diagram  in  ctmtrol  ^ledfication 

*  A  oommonfy  used  nupping  for  teamMuorli;  four-variaUe  relations  is  to  a  control  bar  and  a  corresponding 
dedsion  table. 


It  is  not  obvious  from  'Dible  5  how  CoRE  makes  use  of  context  diagrams.  A  CoRE  context  diagram 
b  used  in  much  the  same  way  as  with  Uamworic.  the  central  transformadmi  represents  the  qrstem  to 
be  built,  and  terminators  represent  external  entities  that  have  an  effect  on  the  ^tem.  The  most  signifi¬ 
cant  difference  is,  however,  that  on  the  CoRE  context  diagram,  arrows  between  terminators  and  the 
transformation  represent  environmental  variables,  not  necessarily  the  flow  of  data. 

€3  USING  THE  RDD-100  BRIDGE  TO  TEAMIFOlUr  FOR  Core 

Of  ail  the  objects  in  the  tuaanvork  model  generated  by  RDD-lOffs  teamwork  filter,  the  most  useful 
part,  in  CoRE*s  perspective,  is  the  context  diagram.  However,  it  probably  will  need  modification  for 
use  by  CoRE.  Tl^minators  on  the  teamwork  context  diagram  are  mapped  from  RDD-100  Component 
elements  of  type  BxiemdSystem,  vdiose  behavior  is  desaibed  using  TlmeFuncUom.  Although  this  map- 
png  is  useful  for  CoRE,  it  will  not  always  be  a  precise  mapping  to  CoRE  terminators,  whidi  represent 
either  sources  of  monitored  variables  or  targets  of  controlled  variables.  Data  flows  on  the  Co]^  con¬ 
text  diagram  are  equivalent  to  monitored  and  controlled  variables.  Hie  context  diagram  generated 
by  RDD-100  may  not  adhere  to  this  convention.  The  HAS  Bu(^  Context  Diagram  of  the  HAS  Buoy 
case  study  (Section  ^ip.  3.2.1)  provides  an  example  of  the  context  diagram  generated  by  RDD-100. 

The  data  dictionary  generated  RDD-lOO's  teamwork  filter  provides  useful  definitions  for  CoRE. 
For  example,  viien  a  data  flow  on  the  teamwork  contort  diagram  generated  by  RDD-100  maps  to  a 
Core  environmental  variable,  the  data  dictionary  entry  for  the  data  flow  is  useful  as  the  spedfication 
of  the  environmental  variable. 

Attributes  of  the  source  RDD-100  elements  are  provided  in  the  generated  data  dictionary  entries  (see 
Ihble  6).  Most  of  these  attribute  values  are  useful  for  a  CoRE  specification.  For  example,  the  mini¬ 
mum  vdue,  maximum  value,  and  units  fields  in  Thbie  6  are  useful  when  defining  CoRE’s  input  and 
output  data  items.  However,  some  of  these  attributes  may  not  be  useful,  such  as  RDDJiype,  shown 
in'^lefi. 
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1)11)10  6.  Saoqile  Generated  Data  DictKHiaiy  Entiy 

Air_Taaperature_DI  (data  flov,  pal)  « 

*  An  environamttal  variable  describing  the  atansphere.  * 


Author 

Creation  Date 
Modification  Date 
Modification  Tina 
Mininun  Value 
Maxinun  Value 
Mean  Value 
units 
Sixe 

Iten  Type 
RDD  Type 


Syst«a  User; 

11  August  1993; 
7  October  1993; 
3:36:00  pn; 
-40.0; 

60.0; 

20.0; 

degree  Celsius; 
1; 

physical; 

nessage; 


When  ixMmuvotk  objects  are  created  usiDg  RDD-lOO’s  filter,  RDD-100  is  forced  to  generate  labels  for 
certain  objects,  sudi  as  transformations  and  data  flows.  RDD-100  has  adopted  a  convention  for  identi¬ 
fying  sources  of  those  ttammuk  objects  in  the  RDD-100  database.  For  example,  the  sufBx  "^DI”  is 
added  to  the  labels  of  itamwork  objects  mapped  firom  DiscnteHems^  ami  the  sufBx  “JIK*  is  added  to 
the  labels  of  ttamwwk  objects  map^  from  TlmeFimcdons.  These  labels  are  generally  effective  in  con- 
v^ng  the  purposes  of  the  objects  and  traceabilify  bade  to  the  RDD-100  model.  However,  maintaining 
these  labefr  may  become  burdensome  for  the  GoRE  practitioner  using  teamtvorfc,  and  it  may  be  a  use¬ 
ful  exerdse  to  strip  those  suffixes  from  the  ttamwork  objects  after  the  traceabilify  from  RDD-100  to 
ttanworic  is  understood  and  recorded. 


The  lower  level  (below  level  0)  data  flow/control  flow  diagrams  and  p-specs  generated  by  RDD-100 
are  based  on  the  hierarchy  of  T/meFunctfons  in  the  RDD-100  model.  These  diagrams  indicate  the  rela¬ 
tionships  between  TimeFun^'on,  Discr^eFuncUon,  Timeltem,  Discr^eltem,  and  DataStom  elements  in 
the  RDD-100  model  according  to  the  mapping  in  Tkble  4.  Lower  level  data  flow/control  flow  diagrams 
in  Core  are  used  to  spedfy  requirements  dass  hierarchies,  organized  into  classes.  Aify  effective  use 
of  the  RDD-lOO’s  automatically  generated  data  flow/control  flow  diagram  hierardiy  for  CoRE  would 
be  coinddental  because  aiteria  for  building  a  hierardiy  of  RDD-100  TimeFunctions  are  unrelated  to 
the  aiteria  for  building  a  CoRE  requirements  class  hierardiy. 
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APPENDIX:  HAS  BUOY  CASE  STUDY 


This  appendix  contains  exani(des  from  the  HAS  Buoy  ^tem  case  study.  The  examples  were  selected 
with  the  intent  to  illustrate  application  of  the  guidelines  contained  in  this  report. 

Sectkm  App.l  contains  the  document  that  records  the  HAS  Buoy  problem  statement  upon  which  the 
case  stiuty  was  based.  Section  Ai^.2  contains  the  RDD>100  system  design  of  the  HAS  Buoy  built  from 
the  prc^lem  statement  of  Section  App.l.  Section  App3  contains  the  CoRE  model  for  the  HAS  Buoy 
that  was  derived  based  on  the  RDD-100  model  in  S^ion  A{^.2. 

AFRl  HAS  BUOY  PROBLEM  STATEMENT 

This  section  contains  the  document  that  records  the  HAS  Buoy  problem  statement  upon  which  the 
case  study  was  based.  The  problem  statement  was  adapted  from  Software  Eng^eringPrindples  (Naval 
Researdi  Laboratory  1980). 

App.1.1  Introduction 

The  Navy  intends  to  deploy  HAS  buoys  to  provide  navigation  and  weather  data  to  air  and  ship  traffic 
at  sea.  The  buoys  will  collect  wind,  temperature,  and  location  data  and  will  periodically  broadcast  sum¬ 
maries.  Passing  vessels  will  be  able  to  request  more  detailed  information.  In  addition,  HAS  buoys  will 
be  deployed  in  the  event  of  accidents  at  sea  to  aid  sea  search  operations. 

App.1.2  Hardware 

Each  HAS  buc^  will  contain  a  small  computer,  a  set  of  wind  and  temperature  sensors,  and  a  radio 
receiver  and  transmitter.  The  temperature  sensors  take  air  and  water  temperature  (Centigrade). 
Each  buoy  will  have  one  or  more  wind  sensors  to  observe  wind  magnitude  in  knots  and  one  or  more 
wind  sensors  to  observe  wind  direction.  Bu<^  geographic  position  is  determined  by  use  of  a  radio 
receiver  link  with  the  Omega  navigation  ^tem. 

Some  HAS  buc^  are  also  equipped  with  a  red  light  and  an  emergency  button.  The  red  light  may  be 
made  to  flash  a  request  radioed  from  a  vessel  during  a  sea  search  operation.  If  the  sailors  are  able 
to  readi  the  buoy,  th^  may  press  the  emergency  button  to  initiate  SOS  broadcasts  from  the  buoy. 

App.l3  Software  REQUQUEAfENTS 

The  software  for  the  HAS  buoy  must  satisfy  the  following  requirements: 

•  Maintain  current  wind  and  temperature  information  by  monitoring  sensors  regularly  and 
averaging  readings. 
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ySfPfdir  HAS  Buoy  Cite  Stu<?/ 


•  Calculate  location  via  the  Omega  navigation  system. 

•  Broadcast  wind  and  temperature  information  every  60  seconds. 

•  Broadcast  more  detailed  reports  in  response  to  requests  from  passing  vessels.  Tue 
information  broadcast  and  the  data  rate  will  depend  on  the  type  of  vessel  making  the  request 
(ship  or  airplane).  All  requests  and  reports  will  be  transmitt^  in  the  RAINFORM  format. 

•  Broadcast  weather  history  information  in  response  to  requests  from  ships  or  satellites.  The 
history  report  consists  of  the  periodic  60-second  reports  from  the  last  48  hours. 

•  Broadcast  an  SOS  signal  in  place  of  the  ordinary  60-second  message  after  a  sailor  presses  the 
emergen(y  button.  This  should  continue  until  a  vessel  sends  a  reset  signal. 

•  Cause  the  red  light  to  start  and  stop  flashing  in  response  to  requests  from  passing  vessels. 

•  Accept  external  update  data.  Although  HAS  bu(^  calculate  their  own  position,  they  must  also 
accept  correction  information  from  passing  vessels.  The  software  must  use  the  information  to 
update  its  internal  database. 

App.1.4  Software  Timing  Requirements 

In  order  to  maintain  accurate  information,  readings  must  be  taken  from  the  sensing  devices  at  the 
following  fixed  intervals: 

temperature  sensors:  every  10  seconds 
wind  sensors:  eveiy  30  seconds 


App.1.5  Priorities 


Since  the  buoy  can  transmit  only  one  report  at  a  time,  conflicts  will  arise. 

If  the  transmitter  is  free  and  more  than  one  report  is  ready,  the  next  report  will  be  chosen  according 
to  the  following  priority  ranking: 


SOS 

Periodic 

Airplane  Request 
Ship  Request 
Weather  History 


1  highest 
1 

2 

3 

4  lowest 


App.1.6  HAS  Buoy  Stabilities  and  Variabiuties 


This  section  identifies  additional  requirements  imposed  onto  the  HAS  Buoy  system.  Each  of  these 
requirements  is  classified  as  either  stable  (not  likely  to  change)  or  variable  (likely  to  change). 
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The  HAS  Buc^  requirements  that  are  expected  to  change  are  as  follows: 

1.  The  number  of  sensors  of  eadi  type  with  which  it  is  equi]^)ed. 


Appeadijc  HAS  Buoy  Cisc  Stuc^ 


2.  Hie  types  of  sensors  with  whidi  it  is  equipped.  In  addition  to  different  temperature  and  wind  speed 
sensors,  a  &ioy  may  be  equif^ied  with  sonar  sensors,  wave  spectra  sensors,  and  other  sensors  that 
monitor  the  ocean  environment 

3.  The  range,  resolution,  and  response  time  of  the  sensors  used. 

4.  The  frequency  with  which  sensors  are  sampled. 

5.  The  equipment  used  to  determine  location.  Some  buoys  may  use  the  Omega  navigation  ^tem 
and  its  successors.  Others  may  use  inertial  measurement  systems. 

6.  The  sources  of  external  messages  diat  the  buoy  may  receive.  In  addition  to  U.S.  Navy  ships,  some 
buoys  may  receive  messages  from  satellites. 

7.  The  format  of  the  messages  transmitted  and  received  by  the  buoy. 

8.  The  histoiy  interval,  i.e.,  the  length  of  time  of  the  history . 

9.  The  computer  system  used,  including  the  speed,  primary  memory  size,  and  availability  of 
secondary  memory. 

10.  The  number  of  computers  used. 

11.  The  number  and  type  of  radio  transmitters  and  reivers  used. 

12.  The  frequency  with  which  wind  and  temperature  data  will  be  transmitted.  The  expected  frequency 
is  once  per  minute. 

13.  For  some  buoys,  the  position  of  some  sensors  may  have  to  be  recorded,  e.g.,  water  temperature 
sensors  may  be  deliberately  deployed  at  different  depths. 

14.  The  frequency  with  which  various  types  of  BIT  are  performed,  the  types  and  frequencies  of 
occurrence  of  sensor  and  computer  malfunction  that  require  recovery  strategies  to  be  invoked, 
and  the  strategies  for  recovery  from  resource  failure. 

The  HAS  Buoy  requirements  that  are  considered  to  be  stable  are  as  follows: 

1.  The  buoy  is  equipped  with  a  set  of  sensors  that  monitor  environmental  conditions.  The  value  of 
a  particular  environmental  condition  at  a  given  time  is  a  function  of  the  readings  of  sensors  that 
can  measure,  directly  or  indirectly,  the  condition.  (A  typical  function  used  is  the  average.)  The 
number  and  types  of  sensors  onboard  a  particular  buoy  are  fixed  once  the  buoy  begins  operation. 

2.  The  bucty  monitors  at  least  air  and  water  temperature  and  wind  speed.  It  monitors  them  at  its 
location. 

3.  The  bucty  can  determine  its  location  to  within  a  specified  tolerance. 
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4.  The  buoy  maintains  a  finite  history  of  the  environmental  data  it  has  collected,  a  history  of  its 
location,  and  a  correlation  between  the  two.  Included  in  the  history  is  the  time  at  which  data  were 
collected.  The  required  length  of  the  history  does  not  change  once  the  buoy  begins  operation. 

5.  The  buoy  is  equipped  with  at  least  one  radio  transmitter  and  at  least  one  receiver  that  enable  it 
to  receive  and  transmit  messages.  It  shall  at  least  be  able  to  receive  messages  from  passing  U.S. 
Navy  ships  in  the  standard  RAINFORM  format. 

6.  The  buoy  transmits  messages  containing  current  wind  and  temperature  information  periodically. 
The  period  does  not  change  once  the  buoy  begins  operation. 

7.  The  buoy  will  respond  to  requests  that  it  receives,  via  radio,  to  transmit  more  detailed  reports  on 
environmental  conditions  and  to  transmit  weather  history  information,  induding  both  weather 
data  and  the  location  and  time  at  which  the  weather  conditions  occurred. 

8.  The  buoy  is  equipped  with  an  emergency  switch,  vdiidi,  when  flipped,  causes  the  buoy  to  transmit 
an  SOS  signal  in  place  of  its  periodic  wind  and  temperature  reports.  The  SOS  signal  ceases  when 
the  buoy  receives  a  reset  message. 

9.  When  the  location  as  determined  by  the  buoy  is  significantly  different  from  the  location  supplied 
externally,  the  buoy  will  use  self-diagnostics  to  attempt  to  determine  and  eliminate  the  source  of 
the  error.  The  criteria  for  significantly  different  are  fixed  once  the  buoy  begins  operation. 

10.  The  buoy  shall  fimction  without  noticeable  degradation  with  damage  to  up  to  20%  of  its  sensors. 
If  more  than  20%  are  improperly  functioning,  both  periodic  and  request  reports  shall  be  marked 
suspea.  In  the  event  that  data  are  considered  unusable,  a  defective  report  shall  be  sent  in  place 
of  Ae  suspect  data. 

APR2  HAS  BUOY  RDD-100  MODEL 

This  section  contains  the  RDD-100  system  design  of  the  HAS  Buoy  built  from  the  problem  statement 
of  Section  App.l.  The  RDD-100  model  of  the  HAS  Buoy  system  is  most  easily  represented  in  a  report 
providing  the  RDD-100  SEN  for  the  system. 

The  RDD-100  S04  provides  a  report  including  a  complete  description  of  all  of  the  information  in  the 
RDD-100  database.  However,  much  of  this  information  is  not  applicable  for  the  software  require¬ 
ments  engineer  using  CoRE  (see  Section  5) .  Therefore,  only  those  parts  of  the  SEN  that  are  of  interest 
to  Core  users  are  included  in  this  section.  In  particular,  the  following  portions  of  the  SEN  are  not 
included  in  this  section: 

•  Section  5,  Hierarchical  Function  List 

•  Section  6,  Intern  Functional  Behavior  Description 

Note  that  the  RDD-100  notational  conventions  have  been  adhered  to  as  closely  as  possible.  That  is: 

•  Major  subsections  are  numbered  (e.g.,  App.2.1  ^tem  Ibp-Level  Description). 

•  Minor  subsections  are  in  bol4faced  italicized  ixrif  font. 
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•  Relationships  and  attributes  of  elements  are  in  italicized  serif  font. 

An  additional  convention  has  been  adopted  for  this  report:  RDD-100  database  elements  that  are  not 
expected  to  be  of  interest  to  CoRE  are  named  with  ail  lower  case  letters  (e.g.,  “sensor  interface  box” 
instead  of  “Sensor  Interface  Box”). 

App.2.1  System  Top-Level  DESCRipnoN 
HASBuoy 

Putpase:  This  is  the  set  of  all  requirements  for  the  overall  buoy  system. 

BwUFrom  Components: 

External  System:  Air 
System:  HAS  Buoy 


1.1 

sensors  package 
Subsystem:  1.1.1 

Sensors 

1.1.2 

sensor  interface  box 

1.2 

communications  package 

1.2.1 

comm  interface  box 

Subsystem:  1.2.2 

transmitter 

Subsystem:  1.2.3 

receiver 

1.3 

other  padrages 

External  System:  light 
External  System:  Omega  System 
External  System:  Sailor 
External  System:  Vessel 
External  System:  ^ter 

External  Interfaces 

^tem-Level  Performance  Requirements: 

Air  Temperature  Accuracy 
Period  Accuracy  to  10% 

V^ter  Temperature  Accuracy 

Source  Document:  HAS  ADARTS  Problem  Statement 

Performs  Top-Level  Function: 

HAS  Buoy  (see  Figure  8).  Note:  Although  the  Abstract  Object  Editor  is  provided  in  Release  4.0  of 
RDD-100  (not  Version  3.0.2),  Figure  9,  whidi  requires  the  Abstract  Object  Editor,  is  included  be¬ 
cause  it  illustrates  the  effectiveness  of  the  newtool  for  supporting  CoRE.  Note  that  Figure  9  identifies 
those  Dlscretelterm  that  may  map  to  CoRE  environmental  variables. 


41 


42 


Figure  8.  HAS  Buoy  Behavior  Model 
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Inpax 


:  HAS  BacyCMe  Study 


Air  Ibmpaature  source:  ExtermlSystem:  Air 
Buoy  Location  source:  ExtemalSysiem:  Omega  System 
Emeigeacy  Button  source:  ExternalSystem:  Sailor 
Vessel  Request  source:  ExtemalSysUm:  Vessel 
VJIsta  Ibn^ature  source:  ExternalSystem:  Water 
Dire^on  source:  ExternalSystem:  Air 
Wind  Magnitude  xmrce:  ExternalSystem:  Air 

Outputs 

Red  Li^t  destination:  ExternalSystem:  Light 
Repot  destination:  ExternalSystem:  Vessel 

Firsi~Levd  l^em  Functions: 

HAS  Buoy  TbneFunction:  0  Buoy  Performance 

AppJ.2  System-Level  (Originating)  Requirements 

In  order  to  reduce  the  size  of  this  document  only  a  few  system-level  requirements  are  provided  in  their 
entirety  for  exemplary  purposes.  Only  the  names  of  the  remaining  tystem-level  requirements  are 
provided. 

AirTimperature 

Description: 

The  buoy  monitors  at  least  air  and  water  temperature  and  wind  speed.  It  monitors  them  at  its  location. 
Traces  To:  Performanceindex:  Air  Ibrnperature  Accuracy 
Source  Document:  HAS  Stabilities 
Corntmatications 
Descriptiim: 

The  buoys  will  collect  wind,  temperature,  and  location  data  and  will  periodically  broadcast 
sununaries.  Passing  vessels  will  be  able  to  request  more  detailed  information. 

Incorporates  System  Requirements): 

History  Interval 
Message  Format 
Message  Source 
Nuffiba  of  lYansceiveis 
Re^nse  to  Requests 
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IBrtKes  Hk  Pcrformancelndex:  Period  Accuracy  to  10% 
Sctace  Document:  HAS  ADARTS  Problem  Statement 


Description: 

9.  The  oonqmtor  system  used,  including  the  speed,  primary  memory  size,  and 
availability  of  secondary  memory. 

Source  Document:  HAS  'friabilities 

Emergency  Switch 

Descripticm: 

8.  The  buoy  is  equipped  with  an  emergency  switdi,  whidi,  when  flipped,  causes  the 
buoy  to  transmit  an  SOS  signal  in  place  of  its  poiodic  wind  and  temperature 
reports.  The  SOS  signal  ceases  vdten  the  buoy  receives  a  reset  message. 

Source  Document:  HAS  Stabilities 

Extenud  Location 

Desaynion: 

9.  The  buoy  can  accqrt  location  data  from  extonal  sources,  such  as  passing  ships, 
via  radio  messages.  If  en  the  location  as  determined  by  the  buoy  is  signiGcantly 
difiemit  from  the  location  supplied  externally,  the  buoy  will  use 
self-diagnostics  to  att'''npt  to  determine  and  eliminate  the  source  of  the  error. 

The  critoia  for  signifiv<intly  differmt  are  fixed  cmce  the  buoy  begins  operation. 

Inanpomtes  System  Requirement(s):  Self  Diagnosis 

Source  Docmnent:  HAS  Stabilities 

Fixed  Periodicity 

Dextptitm: 

6.  The  buoy  transmits  messages  containing  currrait  wind  and  temperature  information 
poiodically.  The  period  does  not  diange  once  the  buoy  begins  operation. 

Source  Document:  HAS  Stabilities 

Gravid  Degradation 

Desaiptim: 

10.  The  buoy  shall  function  without  noticeable  degradation  with  damage  to  up  to  20%  of  its  sensors. 
If  more  than  20%  are  improperly  functioning,  both  periodic  and  request  reports  shall  be  marked 
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si^)ect.  In  the  evoit  that  data  are  considered  unusable,  a  defective  report  be  sent  in  place  of  the 

su^wctdata. 

Jneoipomtes  System  Requinment(s):  Suspect  Reports 

Source  Document:  HAS  Stabilities 

lUurdmue 

Descr^aion: 

Each  HAS  buoy  will  ccmtain  a  small  computer,  a  set  of  wind  and  temperature  sensms,  and  a  radio 
receivear  and  transmitter.  The  temperature  srasors  take  air  and  water  tempoature  (Centigrade).  Each 
buoy  will  have  one  or  more  wind  sensors  to  observe  wind  magnitude  in  knots  and  (me  or  mcne  wind 
sensors  to  observe  wind  direction.  Buoy  geographic  position  is  determined  by  use  of  a  radio  receiver 
link  with  the  Omega  naviption  system. 

Some  HAS  tmoys  are  also  equipped  with  a  red  ligbt  and  an  emetgoicy  button.  The  red  light  may  be 
made  to  fla^  by  a  request  radioed  from  a  vessel  during  a  sea  search  (^>eration.  If  the  sail(»s  are  able 
to  reach  the  buoy,  they  may  press  the  emergency  button  to  initiate  SOS  broadcasts  from  the  buoy. 

Incoeporates  System  Requirement(s): 

Communications 
Computer 
Emeqiency  Switch 
Graceful  Degradation 
History  Interval 
Malfunctions 
Message  Format 
Message  Source 
Number  of  Computes 
Number  of  IVao^vers 
Response  to  Requests 
S^xqrect  Rqx)rts 

Source  Document:  HAS  ADAPTS  Ftoblem  Statement 
History  Interval 

Descr^on:  8.  The  history  interval,  i.e.,  the  length  of  time  of  the  history. 

Source  Document:  HAS  "Viabilities 


Descryrtion: 

4.  The  buoy  maintains  a  finite  history  of  the  environmmtal  data  it  has  collected,  a  history  of  its 
location,  and  a  cotrelaticm  betwem  the  two.  Intdoded  in  the  history  is  the  time  at  >Kiiich  data  vfcie 
collected.  The  required  loigth  of  the  history  does  not  change  once  the  buoy  begins  operation. 
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Source  Doamaa:  HAS  Stabilities 

The  remainii^  ^tem-level  requirements  are  listed  by  name  only. 
lACUSoti 

Laaohitlbknmee 

AU^ImeAHtt 

MeoaftFiumat 

MeauftSottnt 

MSHimum  Communications 

Numbtrt^Comp 

Ntanbsrsfnranscdms 

Prlmida 

Rt^masm  Requests 

StHfDiaptosis 

Sense  Environment 

SensmNimUter 

SensorReriod 

Sensor  RositionReconBi^ 

SensmrRange 

Sensor 

Sensors 

Sqfiware  Requirements 
Sefitvare  Tiling 
Suspect  Rqports 
JYunsmission  Period 
HbSer  Tkmpeevture 
WbedSpeed 
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DBSKN  CONSTRAIKTS 

Cm 

Deaer^nbm:  Tlie  buoy’s  parts  shouldn’t  cost  more  than  $2,000. 

CtmstrainK 

Decision:  Available  Hardware 
Decision:  l>wo  Fmnats 

JhacedRom:  Dedsicm:  Two  Formats 

RUNFORM  Rfnnat 

Desa^dan: 

The  buoy ...  shall  at  least  be  able  to  receive  messages  from  passing  U.S.  Navy  ships  in  the  standard 
RAINFORM  format 

Dmnain  Stabilities,  #5 

Constndns: 

CSriticallssiie:  How  Many  Formats? 

Decision:  Two  Formats 

ThuedRom: 

Oriticalksue:  How  Many  Fcmnats? 

SystemRequirement:  Message  Format 
SystemRequiremoit:  Message  Source 
Decision:  Two  Fmmats 

AfpJLA  Issues  a  Decisions 
DedsUmsdiat  trace  from  Q^ieal  Issues 
bsue:  Rror  Correction? 

Originator  ^tem  User 
(^iginedm  Date:  23  August  1993 
DesaqrdotK 

How  is  the  required  error  correction  to  be  p^ormed? 

Fitom  #9,  "HAS  Stabilities”:  "When  the  location  as  determined  by  the  buoy  is  significantly  difierent 
firotn  the  location  supplied  extonally,  the  buoy  will  use  self-diagnostics  to  attempt  to  determine  and 
eliminate  the  source  of  the  error.  The  criteria  for  significantly  diffnent  are  fixed  once  the  buoy  begins 
operation.” 
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Source  Document:  HAS  Stal^ities 
JheeedDvm: 

SystemRequiianart:  Location  Tolerance 
SyManReqiiiiement:  MalfiincticMis 

Thaees  Tb:  Source:  HAS  Stabilities 

btm:  Beiw  Meaty  Pamats? 

OrigbMtor  System  User 

Or^tuttUm  Date:  23  Au^t  1993 

Desa^ttion: 

At  least  one  fmnat  must  be  recognized  to  message  passing  (standard  RAINFORM  format).  Are 
ottiecs  required  by  die  existing  vessels’  communications  gear?  How  many  others  are  desirable? 

ThrcedRom:  Decision:  IIno  Formats 

Threes  1b: 

Source:  HAS  Stabilities 
Constraint:  RAINFORM  Format 

Mssue:  How  Much  History? 

Ongmaton  System  User 

Origination  Date:  23  August  1993 

DesaiptiotK 

What  is  the  longest  history  trail  required  ai^  HAS  buoy? 

#4  in  Source:  ’The  buoy  maintains  a  finite  history  of  the  environmental  data  it  has  collected,  a  history 
of  its  locatitm,  and  a  correlation  betweoi  the  two.  Induded  in  the  history  is  the  time  at  which  data 
were  collected.” 

Source  Document:  HAS  Stabilities 

2hiced  Horn:  Decision:  Available  Hardware 

Thaees  Tb:  Source:  HAS  Stabilities 

Deddons  that  do  rwt  trace  from  Critical  Issues 

Dedsiom  Available  Hardware 

.^[/proved  By:  ^tem  User 
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Approval  Date:  23  August  1993 
Deser^pdon: 

Hstory  will  be  kqH  based  on  the  available  RAM  memory  |m>vided  in  the  onboard  computer.  No 
ifwclfic  added  provlskm  will  be  added,  to  contain  costs. 

Prottem: 

The  buoy  maintains  a  finite  history  of  the  environmental  data  it  has  collected,  a  history  of  its  location, 
and  a  correlation  between  the  two.  Induded  in  the  history  is  the  time  at  wdtich  data  wm  collected. 
The  required  length  of  the  histny  does  not  change  once  the  buoy  begins  opoation. 

Altematwex 

1)  If  a  long  string  of  history  is  not  a  necessity,  history  should  be  kept  based  only  on  the  available  RAM 
mem(»y  provided  in  the  onboard  compute; 

2)  If  a  long  string  of  history  is  important,  extra  RAM  memtxy  should  be  provided  in  the  onboard 
computer. 

Chtdce:  No.  1  is  chosen,  pending  further  notice. 

Source  Document:  HAS  ADABTS  Problem  Statement 
Jhuxs  Hk  Criticallssue:  How  Much  History? 

DetidomTVfo  Formats 
Aj^troved  By:  ^tem  User 
Approval  Date:  23  August  1993 

Desaption:  RAINFORM  format  will  be  supported,  and  a  standard  SOS  format  will  be  supported. 
Problem: 

The  buoy  is  equipped  with  at  least  one  radio  transmitter  and  at  least  one  receiver  that  oiable  it  to 
receive  and  transmit  messages.  It  shall  at  least  be  able  to  receive  messages  Grom  passing  U.S.  Navy 
diips  in  the  standard  RAINFORM  format. 

Alternatives: 

1)  The  explicit  requirem'^  rmly  for  RAINFORM. 

2)  But,  the  critical  nature  of  SOSes  suggests  recognizing  oldo’  formats  as  well. 

3)  Flexibility  would  be  improved  if  an  onboard  mechanism  to  vary  selection  of  formats  was 
provided. 
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Choice:  #2  was  chosen,  the  3rd  running  afoul  cost  constraints. 
So$uce  Docunterti:  HAS  Stabilities 
’Duces  Tb: 


Constraint:  Cost 

Qriticallssue:  How  Many  Fomutts? 

SystemRequirement:  Message  Fonnat 
SystemRequiremoit:  Message  Source 
SystemRequirement:  Minimum  Communications 
Constraint:  RAINFORM  Format 

AppJS3  Performance  Indices 
Mr’RmpeteSiaeAcamiqf 

Desorption:  Air  temperature  must  be  kept  to  within  1  degree  Centigrade. 

Units: 

Value: 

Category:  Measurement 

ExMtit^By: 

Compmient:  HAS  Buoy 
Systm:  HAS  Buoy 
ComiKment:  1.1.1  -  Sensors 

’DacedFirom: 

SystemRequirement:  Air  Temperature 
SystemRequiremoit:  Sensors 

Fariod  Accuracy  to  10% 

Desaypdon: 

The  broadcast  cyde  must  be  accurate  to  >xdthin  3  seconds  for  the  wind  sensors,  and 
1  second  for  the  temperature  sensors. 

Units: 

Vdue: 

Category:  Measurement 

ExJulntedBy: 

Component:  HAS  Buoy 
SystCT:  HAS  Buoy 
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OonqxMMiit:  1.2  -  oommuiiicaU<xis  package 
Oomponeat:  1.2.2  -  transmitter 

UfocedFhmv 

SystemRequircment:  Communications 
SystemRequirmnern:  Software  Timing 

WalurTea^enttinAeainey 

Description:  Water  temperature  must  be  kept  to  within  1  degree  Centigrade. 

UrUts: 

l^bte: 

Cat^ory:  Measurement 

ExhibitedBy: 

Component:  HAS  Buoy 
System:  HAS  Buoy 
Component:  1.1.1  -  Sensors 

ThtcedFirom: 

SystemRequirement:  Sensors 
SystemRequirement:  Water  Temperature 

Item  DicnoNAmr 
aeknowledganent 
OugrutEmm: 

Componoit:  1.2  communications  package 
Componmit:  1.2.1  comm  interface  box 
DiscreteFbnetion:  2.1.1  receive  messap 
(Allocated  Onto:  Component:  comm  interface  box) 


Input  Jb: 

Componort:  1.1  sensors  package 
Comptment:  1.1.2  sensor  interface  box 
DiscreteFunction:  1.2.2  wait  for  ack 
(Allocated  Onto:  Component:  sensor  interface  box) 

AirTai^peruture 

DesafiaUm:  An  environmental  variable  describing  the  atmosphere. 
Output  Rom:  Extemal^tem:  Air 
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Input  Hk 

System:  HAS  Buoy 
Gou^xmeiit:  1  simple  WB 

System:  HAS  Buoy 
Con^Kment:  1.1  sensors  package 
Subsystem:  1.1.1  Soisois 
DiscreteFtinction:  1.1.1  gather  periodic  samples 
(Allocated  Onto:  &tbsystem:  Sensors) 

Allocated  to  Cmnptment:  External  System:  Air 

BueyLoattion 

Descrqnion:  An  environmental  variable  describing  where  the  HAS  buoy  is  situated. 

Ou^utRvm:  ExtemalSystem:  Omega  System 
Input  Tb: 

System:  HAS  Buoy 
Compcment:  1  simple  WB 
System:  HAS  Buoy 

Component:  1.2  communications  package 
Subsystem:  1.2.3  receiver 
DiscreteFunction:  2.3.1  receive  navigation  signal 
(Allocated  Onto:  Subsystem:  receiver) 

Allocated  to  Component:  External  System:  Omega  System 

roUfclfd  data 

Output  Exmi: 

Subsystem:  1.1.1  Sensors 
DiscreteFlmction:  1.1.1  gather  periodic  samples 
(Allocated  Onto:  Subsystem:  Sensors) 

Irq/ut  lb: 

Component.  1.1.2  soisor  int^ace  box 
DisaeteFunction:  1.2.1  said  message 
(Allocated  Onto:  Component:  sensor  interface  box) 

Emergency  Button 

Description: 

An  aivironmoital  variable  describing  vdiether  a  sailor  has  gotten  to  the  HAS  buoy  and  pressed  the 
Initton  to  cut  on  the  emergoicy  beacon. 


53 


App««dhc  HAS  Biioy  Cmc  Study 


OuijNtf />om;Ezternal^tem:  Sailor 

Input  Ti/c 

System:  HAS  Buoy 

Component:  1  simple  WB 

System:  HAS  Buoy 

Component:  1.1  sensors  package 

Subsystem:  1.1.1  Sensors 

Disc^Ftmction:  1.1.1  gather  periodic  samples 

(Allocate  Onto:  Subsystem:  Sensors) 

Allocated  to  Component:  External  System:  Sailor 


Output  Rom: 

Con^xmeat:  1.1  sensors  padcage 
Component:  1.1.2  sensor  interface  box 
DiscreteFimcdon:  1.2.1  send  message 
(Allocated  Onto:  Component:  sensor  interface  box) 

Input  Jb: 

Component:  1.2  communications  padcage 
Comptment:  1.2.1  comm  intoface  box 
DiscreteFbncti(«:  2.1.1  receive  message 
(Allocated  Onto:  Conponent:  comm  interface  box) 

RedUght 

Description: 

An  environmental  variable  describing  ^^ether  the  emergency  beacon  is  turned  on  or  not 

OutputRmi: 

System:  HAS  Buoy 
Component:  1  simple  WB 
System:  HAS  Buoy 

dompmmit:  1.2  communications  package 
Subsystem:  1.2.2  transmitter 
DisoeteFbnction:  2.2.2  transmit  one  singular 

Input  Tb:  ExtemalSystem:  Light 

Allocated  to  Component:  External  System:  Light 
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Report 

DescriptUm: 

An  environmental  variable  embodying  the  weather  and  location  report  previously  requested. 

OuqmtRvm: 

System:  HAS  Buoy 
Component:  1  simple  WB 

System:  HAS  Buoy 

Component:  1.2  communications  package 
Subsystem:  1.2.2  transmitter 
DiscreteFbnction:  2.2.1  transmit  one  periodic 
(Allocated  Onto:  Subsystem:  transmitter) 

Input  To:  ExtemalSystem:  Vessel 

Allocated  to  Component:  External  System:  Vessel 

transmit  item 

Output  From: 

Component:  1.2.1  comm  interface  box 
DiscreteFhnction:  2.1.1  receive  message 
(Allocated  Onto:  Component:  comm  interface  box) 

Input  To: 

Subsystem:  1.2.2  transmitter 
DisaeteFunction:  2.2.1  transmit  one  periodic 
(Allocated  Onto:  Subsystem:  transmitter) 

VessdRequest 

DexriptUm: 

An  environmental  variable  desaibing  a  vessel’s  desire  to  get  a  current  weather  and/or  location  report. 
Ou^mtFrtm:  ExtemalSystem:  Vessel 
Input  To: 

System:  HAS  Buoy 

Component:  1  simple  WB 

System:  HAS  Buoy 

Component:  1.1  sensors  package 

Subsystem:  1.1.1  Sensors 

DisoreteFunction:  1.1.1  gather  periodic  samples 

(Allocated  Onto:  Subsystem:  Sensors) 
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Allocated  to  Component:  External  ^tem:  Vessel 
Water  Tea^enture 

Desapdon:  An  environmental  variable  describing  the  surrounding  ocean. 

Output  Rom:  ExtemalSystem:  Water 
InjattTb: 

System:  HAS  Buoy 
Component:  1  simple  WB 
System:  HAS  Buoy 
Cbn^nent:  1.1  sensors  package 
Subsystem:  1.1.1  Sensors 
DisaeteFunction:  1.1.1  gather  periodic  samples 
(Allocated  Onto:  Subsystem:  Sensors) 

Allocated  to  Component:  External  System:  Witer 

WiadlXrecdon 

Desaipdtm:  An  environmental  variable  describing  which  way  the  wind  is  blowing. 
Output  Rom:  ExtemalSystem:  Air 
Input  To: 

System:  HAS  Buoy 
Component:  1  simple  WB 
System:  HAS  Buoy 
Component:  1.1  sensors  package 
Subsystem:  1.1.1  Sensors 
DisaeteFunction:  1.1.1  gather  periodic  samples 
(Allocated  Onto:  Subsystem:  Sensors) 

Carried  by  interface  link:  A^nd  Direction 

Allocated  to  Component:  External  System:  Air 

WindMt^nitude 

Descripdon:  An  environmental  variable  desaibing  how  big  the  wind  is. 

Output  Rom:  ExtemalSystem:  Air 
Input  To: 

System:  HAS  Buoy 
Component:  1  simple  WB 
System:  HAS  Buoy 
Component:  1.1  sensors  package 
Subsystem:  1.1.1  Sensors 
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DisoeteFuncUon:  1.1.1  gather  periodic  samples 
(Allocated  Onto:  Sitbsystem:  Sensors) 

Allocated  to  Component:  External  System:  Air 
App^7  Components 

In  order  to  reduce  the  size  of  this  document,  this  section  describes  only  a  subset  of  the  Components 
in  their  entirety.  All  of  the  Components,  however,  are  identified.  Figure  10  illustrates  the  component 
hierard^  described  in  this  section. 

Air 

Component  "type:  External  System 

Desaynkm:  HAS  Buoy  must  perform  measurements  of  the  atmosphere. 

Builds  Hi^her-Levd  Comptment/System: 

ExtemalSystem:  Air 
System:  HAS  Buoy 

Allocated  Items: 

Oiscreteltem:  Air  Temperature 
Discreteltem:  l^^d  Direction 
Disaeteltem:  IVind  Magnitude 

HAS  Buoy 

Component  "type:  System 
Desaiptim: 

HAS  Buoy  is  the  internal  part  of  the  system,  comprising  all  hardware  and  its  embedded  software. 
Bwlds  Higher-Level  ComponentlSystem:  System:  HAS  Buoy 
BuUt  From  Components: 

1.1  sensors  package 

1.2  communications  package 

1.3  other  packages 

Allocated  Functions: 

HmeFunction:  0  Buoy  Performance 
TimeFunction:  1  HAS  Buoy 

Component-Level  Peiformace  Requirements: 

Air  Temperature  Accuracy 
Period  Accurar^  to  10% 
l^ter  Temperature  Accuracy 
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Figure  10.  HAS  Buoy  Component  Hierarchy 


Apixinrih- HAS  Buoy  CMcStedy 


Comp<ment  ^ipe:  External  System 

DescrifOion:  HAS  Buc^  must  turn  on  a  red  emergency  light  in  this  external  medium. 

BuSds  Higher-Level  CompatentlSystan: 

System:  HAS  Buoy 
ExtemalSystem:  light 

Allocated  Items:  Disaeteltem:  Red  light 

Om^System 

Ctmponent  Tjipe:  External  System 

DescriptUm:  HAS  Bu(^  must  be  located  via  information  from  this  external  medium. 

Builds  Higher-Level  C<mp<mentlSystem: 

System:  HAS  Buoy 
ExtemalSystem:  Omega  System 

Allocated  Items:  Discreteltem:  Buoy  Location 

SaSor 

Cmnpment  "type:  External  System 
Description: 

HAS  Bu(^  must  take  emergency  buuon  pushes  from  this  personal,  but  external,  medium. 

BmUs  Higher-Level  ComponentlSystem: 

System:  HAS  Buoy 
ExtemalSystem:  SaUor 

Allocated  Items:  Disca-eteltem:  Emergency  Button 

W*- - B 

Ffimfi 

Component  Tjfpe:  External  System 

Desorption:  HAS  Buoy  must  receive  requests  from,  and  send  reports  to,  this  external  medium. 

Builds  Higher-Level  ComponentlSystem: 

System:  HAS  Buoy 
ExtemalSystem:  Vessel 
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AUocated  Items: 


IMacreteltem:  Rq)oit 
Disoeteltem:  Vnsel  Request 


— ■  ^  - 

w9UUt 

Component  External  System 

Description:  HAS  Buoy  must  perform  measurements  of  this  external  medium. 

Builds  Higho'-Level  CtmponmtISystan: 

System:  HAS  Buoy 
ExtemalSystem:  ^ter 

Allocated  Items:  Discreteltem:  Water  Ibmperature 
I  simpleWB 
Component  Tfpe: 

Built  Firm  Components: 

1.1  sensors  package 

1.2  communications  package 

1.3  other  padcages 

LI  sensors  packer 
Crmponent  T^pe: 

Builds  Higher-Level  CompcnentfSystem: 

Component:  HAS  Buoy 
Componoit:  1  simple  WB 

Built  Fhm  Components: 

Subsystem:  1.1.1  Smsors 
1.1.2  sensor  intoface  box 

AUocated  FunctUms:  TimeFunction:  1  sensor  functions 
The  remaining  components  are  listed  only  name. 

I.IJ  Sensors 

1,12  saisor  interface  box 


12  communications  paclu^ 


IJH  comun  UKttrfanbox 


i,2t2  HmswICMr 

1^  nedm- 

IJ  odurpaehaies 

Interfaces  Between  Components 
DerimiliUetfices 

t^msFkwu^  ‘'from”  Component:  comm  interface  box 

"into**  Component:  sensor  interface  box 

Diaaeteltem:  acknowledgement 
Output  From;  2.1.1  -  receive  message 
Itqmt  To:  1.2.2  -  wait  for  ack 

Items  Ftowing  "from**  Compement:  comm  interface  box 

"into**  Component:  sensors  padcage 

Disaeteltem:  acknowledgement 
Output  From:  2.1.1  -  receive  message 
Input  To:  1  -  sensor  ftnetUms 

Items  Ftowing  "firom**  Component:  comm  interface  box 

"into**  Subsystem:  transmitter 

Discreteltem:  transmit  item 
Output  From:  2.1.1-  recave  message 
Input  To:  2.2.1  -  transmit  one  periodic 

Items  Flowing  "from**  Component:  communications  package 

"into**  Component:  sensor  interface  box 

Discreteltan:  admowledgement 
Output  From:  2  -  communication  functions 
Itgmt  To:  1.2.2  -  wait  for  ack 

Items  Fkmnng  "firom**  Component:  communications  package 

"into**  Component:  sensors  padcage 

Discreteltem:  acknowledgement 
Output  From:  2  -  comnutnication  functions 
Input  To:  1  -  sens<m  functions 

Items  Flowing  "from**  Component:  sensor  interface  box 

"into**  Component:  comm  interface  box 

Disaeteltem:  intonal  message 
Outjmt  From:  1.2.1  -  send  message 
InpiU  To;  2.1.1  -  receive  message 
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Jtms  /ZoM^  *^01"  Component:  sensor  interface  box 

‘into*’  Component:  oommunications  padcage 

Disaeteltem:  internal  message 
Output  From:  1.2.1  -  send  message 
Input  To:  2  -  commumcatitm  functions 

Items  Flomng  *iroBi**  Subsystem:  Sensors 

*iiito**  Component:  sensor  interface  box 

Disdcteltem:  collected  data 
Output  From:  1.1.1  -  gather  period  samples 
Input  To:  1.2.1  -  send  message 

Items  Flowing  ‘‘firom’*  Component:  sensors  package 

“into**  Component:  comm  interface  box 

Disaeteltem:  internal  message 
Output  From:  1  -  sensor  functions 
Input  To:  2.1.1  -  receive  message 

Items  Flomng  ‘irom**  Component:  sensors  package 

‘into**  Component:  communications  package 

Disaeteltem:  internal  message 
Output  From:  1  -  sensor  functions 
Input  To:  2  -  amumtnication  functions 

Database  Interface  Elements 

communicates 

Ctmnectsto: 

System:  HAS  Buoy 

ExtonalSystem:  Vessel 

Extonal  System:  Vessel 


controls 

Ctmnects  to: 

System:  HAS  Buoy 
ExtonalSystem:  Light 
External  System:  Light 


locates 

Connects  to: 

System:  HAS  Buoy 
ExtonalSystem:  Omega  System 
External  System:  Omega  System 
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ComtectsUK 

ExtemalSystem:  Air 
External  System:  Air 
Sy^on:  HAS  Buoy 
External  System:  Wkter 
ExtemalSy^em:  ^Mtter 

nritdto 

ConnectsUK 

System:  HAS  Buoy 
External  System:  Sailor 
ExtemalSj^tem:  Sail(v 

App^  ShTEM  ^OPERiOIONA]?  PAKAMETEXtS 
This  section  did  not  ap{dy  to  this  case  study. 

APPJ  HAS  BUOY  Core  MODEL 

This  section  contains  the  CoRE  model  for  the  HAS  Buoy  that  was  derived  based  on  the  RDD-100 
model  in  Section  A{^.2.  Section  ^}p3.1  desoribes  howRDD-100  database  elements  of  the  HAS  Buoy 
model  were  mapped  to  CoRE  elements.  Section  App3.2  contains  the  results  of  filtering  the  RDD-100 
model  into  teamMurl:  format  Section  ^)p33  contains  the  remaining  CoRE  work  products  for  the 
HAS  Buoy  i^em. 

App3.1  Mapping  From  RDD-100  to  CoRE 

Ihble  7  summarizes  how  RDD-100  database  elements  map  to  CoRE  inputs  for  the  HAS  Buoy  model, 
acowding  to  the  mapping  specified  in  Section  3.2.  For  each  expected  input  to  CoRE,  Ikble  7  identifies: 

•  The  RDD-100  database  elements  providing  the  necessary  information 

•  An  estimation  of  the  degree  of  completeness  provided  by  the  mapping 

IkUe  7.  Mapping  From  RDD-100  to  CoRE 


Expected  CoRE  Inputs 

RDD-100  Ekmcnt  lype  (HAS  Buoy  Instances) 

Degree  of  Mai^iing 

Mttsion  statement 

Source 

•  HAS  ADARTS  ProUem  Statement 

•  HASStabflities 

•  HASVbiiabiUties 

Complete 

System  model 

FN0t 

•  System  Context  Diagram 

Component 

•  HAS  Buoy  (system) 

•  Air  (external  system) 

•  '^ter  (external  system) 

•  Vessel  (external  ^tem) 

•  Light  (external  system) 

•  Omega  System  (external  system) 

•  Saflor  (external  system) 

Complete 

63 


Ikble  7,  continued 


^atem  requirenoents 
q>ecificatk>o 

•  Air  Ifcmperature 

•  Communications 

•  Computer 

•  Emergency  Switdi 

•  Exter^  Location 

•  Fixed  Periodicity 

•  etc  (see  Section  AppJ22) 

Complete 

System  component  interface 

IrMao* 

C(mi[^te 

qiedfications 

HmUnk 

Dlacntaltam 

TbnaHam 

Requirements  information 

ParionrmnceIndiaK 

Incomplete 

relating  to  ^stem  petfmmaaoe 

•  Air  Tboipeiatuie  Accuracy 

•  Period  Accuracy  to  10% 

•  \ibter  Ihmperature  Accura^ 

'Bible  8  summarizes  how  the  initial  set  of  CoRE  work  products  were  derived  from  RDD-100  database 
elements  for  the  HAS  Buoy  model,  according  to  the  mapping  specified  in  Section  33. 


IkUe  8.  Mapping  From  RDD>100  to  Initial  CoRE  Products 


CoRE  Products 

RDD‘100  Element  ^rpe  (HAS  Buoy  Instances) 

Degree  of  Mapping 

CoRE  information  model 

/ntarftice 

•  communications 

•  oontrob 

•  locates 

•  monitors 

•  switches 

EaarmISystam 

•  Air 

•  Witer 

•  Vessel 

•  Light 

•  Omega  System 

•  Sailor 

Component 

•  HASBuc^ 

Complete 

Candidate  environmental 
variaUes 

DIacreteltem 

•  Vessel  Request 

•  Report 

•  Air  Ihmperature 

•  l\hter  Ihmperaturo 

•  V^d  Magnitude 

•  V/ind  Direction 

•  Buoy  Location 

•  Emergency  Button 

•  Red  light 

Complete 
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IJible  8,  oootinued 


Likely  changes  list 

CriUcmIltaue 

•  Error  Correctwn? 

•  How  Many  Formats? 

•  How  Much  History? 

DeeMon 

•  Available  Hardware 

•  'Two  Formats 

Complete 

Environmental  constraints 
iqiecification  (NAT) 

Conatnkt 

•  Cost 

•  RAINFORM  Format 

Inomnplete 

Ikble  9  summarizes  how  the  additional  CoRE  work  products  were  derived  from  RDD-100  database 
elements  for  the  HAS  Buoy  model,  according  to  the  mapping  specified  in  Section  3.4. 

Ikl]ie9.  Mapfriag  Rom  RDD-100  to  AdditioBal  Core  Products 


CoRE  Products 

RDD-lOO  Element  IQfpe  (HAS  Buoy  Instances) 

Degree  of  Mapping 

Context  diagram 

FNet 

•  System  Context  Diagram 

(Complete 

Monitored  and  controlled  vari- 
aUe  definitions 

DIacnteltem 

•  Vessel  Request 

•  Report 

•  Airlbnqrerature 

•  \Miter  T^perature 

•  V/ind  Magnitude 

•  Direction 

•  Buoy  Location 

•  Emeigeocy  Button 

•  RedUgbt 

Incomplete 

App3^  TEAMN^XK-FaJERED  VERSION  OF  HAS  BUOY 

This  section  contains  those  teamwork  work  products  that  were  generated  by  RDD-lOO’s  teamwork 
filter  from  the  RDD-lOO  model  of  the  HAS  Buoy  system.  Some  parts  of  the  generated  teaimvork 
model  were  not  useful  for  CoRE  and  have  been  omitted. 

Section  App32.1  contains  the  generated  teamwork  process  index,  and  Section  App3.2.2  contains  die 
generated  teamwork  data  dictionary. 

Ibamwork  Process  Index 

The  teamwork  process  indor  generated  RDD-lOO  contained  a  context  diagram,  a  data  flow/control 
flow  diagram  hierarchy,  and  a  number  of  p-specs.  The  context  diagram  was  derived  from  the  behavior 
diagram  for  the  RDD-lOO  System  Component.  Each  data  flow/control  flow  diagram  in  the  hierarct^ 
was  derived  from  a  corresponding  FDD-100  FN^  or  TimeFunctlon.  The  data  flow/control  flow 
diagrams  contained  a  data  transformation  for  each  Discr^eFunction  contained  by  the  F/Vet  or 
UmeFuncUon.  Data  flows  in  and  out  of  data  transformations  were  derived  from  Discreteltems  that  were 
inputs  and  outputs  of  the  Discr^eFunctlons. 
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The  generated  context  diagram  in  Figure  11  turned  out  to  be  ideal  for  CoRE. 


Context— Diasnun:! 
SystemjContext_Diagram_FN 


Figure  11.  HAS  Buoy  Cooteict  Diagram 

Neither  the  generated  data  flow/oontrol  flow  diagrams  nor  the  generated  p-specs  were  useful  for 
Core  because  they  provide  too  low  a  level  of  detail.  The  generated  p-specs  contained  only  input  and 
output  lists. 

App3.2i2  IbamworU  Data  Dictionary 

This  section  contains  the  Uamw<Hk  data  dictionaiy  entries  generated  RDD-100. 

acknowledgement_DI  (data  flow,  pel)  « 

System  User; 

31  January  1992; 

7  October  1993; 

3:35:59  pm; 

1; 

message; 

Alr_Tenperature_DI  (data  flow,  pel) 

*  An  environmental  vruriable  describing  the  atmosphere.  * 


Author 

Creation  Date 
Modification  Date 
Modification  Time 
Size 

ROD  Type 


Author 

Creation  Date 


System  User; 

11  August  1993; 
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Modification  Date 
Modification  Time 
Minimum  Value 
Maximum  Value 
Mean  Value 
Units 
Size 

Item  Type 
ROD  Type 


7  October  1993; 
3 t 36: 00  pm; 
-40.0; 

60.0; 

20.0; 

degree  Celsius; 
1; 

physical; 

message; 


Buoy_Location_Dl  (data  flow,  pel)  ■> 

*  An  environmental  variable  describing  «diere  the  BAS  buoy  is  situated.  * 


Author 

System  User; 

Creation  Date 

11  August  1993; 

Modification  Date 

7  October  1993; 

Modification  Time 

3:36:00  fOii 

Units 

characters; 

Size 

10; 

Item  Type 

data; 

RDD  Type 

message; 

Kljdata_DI  (data  flow. 

pel)  - 

Author 

System  User; 

Creation  Date 

31  January  1992 

Modification  Date 

7  October  1993; 

Modification  Time 

3:36:01  pm; 

Size 

1; 

RDD  Type 

message; 

Bmergency_Button_DZ  (data  flow,  pel)  » 

*  An  environmental  variable  describing  whether  a  sailor  has  gotten  to 
the  BAS  buoy  and  pressed  the  button  to  cut  on  the  emergency  beacon.  * 


Author 

Creation  Date 
Modification  Date 
Modification  Time 
Minimum  Value 
Maximum  Value 
Units 
Size 

Item  Type 
RDD  Type 


System  User; 

11  August  1993; 
7  October  1993; 
3:36:01  pm; 

0.0; 

0.0; 

Bits; 

1; 

digital; 

message; 


intemal_mes8age_DI  (data  flow,  pel)  «> 


Author 

Creation  Date 
Modification  Date 
Modification  Time 


System  User; 

31  January  1992; 
7  October  1993; 
3:36:02  pm; 
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Size  1; 

HDD  Type  message; 


Red_Llght_DI  (data  flow,  pel)  > 

*  An  environmental  veuriable  describing  tdiether  the  emergency  beacon  is 
turned  on  or  not.  * 


Author 

Creation  Date 
Hodification  Date 
Modification  Time 
Minimum  Value 
Maximum  Value 
Units 
Size 

Item  Type 
RDD  Type 


System  User; 

11  August  1993; 
7  October  1993; 
3:36:02  pm; 

0.0; 

0.0; 

Bits; 

Ij 

digital; 

message; 


Report_DI  (data  flow,  j  1)  * 

*  An  environmental  vari«d>le  embodying  the  weather  and  location  report 
previously  requested.* 


Author 

Creation  Date 
Modification  Date 
Modification  Time 
units 
Size 

Item  Type 
RDD  Type 


System  User; 

11  August  1993; 
7  October  1993; 
3:36:02  pm; 
characters; 

100; 

data; 

message; 


transmit_item_DI  (data  flow,  pel)  - 


Author 

Creation  Date 
Modification  Date 
Modification  Time 
Size 

RDD  Type 


System  User; 

31  January  1992; 
7  October  1993; 
3:36:03  pia; 

1; 

message; 


Vessel_Request_DI  (data  flow,  pel)  » 

*  An  environmental  variable  describing  a  vessel's  desire  to  get  a 
current  weather  and/or  location  report.* 


Author 

Creation  Date 
Modification  Date 
Modification  Time 
Units 
Size 

Item  Type 
RDD  Type 


System  User; 

11  August  1993; 
7  October  1993; 
3:36:03  pm; 
characters; 

1; 

data; 

message; 
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Water_Teinperature_DX  (data  flow,  pel)  » 

*  An  environmental  variable  describing  the  surrounding  ocean.  * 


Author 

Creation  Date 
Modification  Date 
Modification  Time 
Minimum  Value 
Maximum  Value 
Units 
?ize 

Item  Type 
RDD  Type 


System  User; 

11  August  1993; 
7  October  1993; 
3:36:04  pm; 

0.0; 

50.0; 

Degree  Celsius; 
1; 

physical; 

message; 


Wind_Direction_DI  (data  flow,  pel)  = 

*  An  environmental  variable  describing  which  way  the  wind  is  blowing.  * 


Author 

Creation  Date 
Modification  Date 
Modification  Time 
Minimum  Value 
Maximum  Value 
Units 
Size 

Item  Type 
RDD  Type 


System  User; 

11  August  1993; 
7  October  1993; 
3:36:04  pm; 

0.0; 

359.9; 

degrees  of  arc; 

1; 

physical; 

message; 


Wind_Hagnitude_Dl  (data  flow,  pel)  >= 

*  An  environmental  variable  describing  how  big  the  wind  is.  * 


Author 

Creation  Date 
Modification  Date 
Modification  Time 
Minimvim  Value 
Maximum  Value 
Mean  Value 
Units 
Size 

Item  Type 
RDD  Type 


System  User; 

11  August  1993; 
7  October  1993; 
3:36:05  pm; 

0.0; 

300.0; 

10.0; 

km/hr; 

1; 

physical; 

message; 


App33  The  Remaining  CoRE  Work  Products 

This  section  contains  the  remaining  CoRE  work  products  that  complete  the  CoRE  specification  for 
the  HAS  Buoy  system.  The  CoRE  specification  was  recorded  using  Cadre’s  teamwork. 

App33.1  CoRE  Information  Model 

The  CoRE  information  model  in  Figure  12  was  recorded  using  a  teamwork  entity-relationship 

diagram. 
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Figure  12.  CoRE  Infcumation  Model 

App33^  Environmental  Variable  Definitions 

Monitored  variables  are  identified  on  the  system  context  diagram  as  system  input  data  flows. 
Controlled  variables  are  identified  on  the  system  context  diagram  as  system  output  data  flows.  The 
data  dictionary  entries  associated  with  the  data  flows  define  the  environmental  variables.  Some 
examples  of  environmental  variable  definitions  are  shown  below. 

HaterTenperature  (data  flow)  » 

Teo^ierature. 


WaterTen^erature  ( MonitoredVeuriable ) 

The  ten^erature  of  the  water  four  feet  below  the 
surface  of  the  water  in  degrees  centigrade. 
TEMPERATURE 
0  ..  100 

HindDirection  (data  flow) 

Direction. 


Variable 

Physicalinterpretation 

Type 

Values 


Veuriable  WindDirection  (MonitoredVeuriedsle) 

Physicalinterpretation  The  direction  the  wind  is  blowing  in  degrees 

(where  0  is  due  north  and  90  is  due  east), 
measured  10  feet  above  the  surface  of  the  water. 
Type  DIRECTION 

Values  0  <=  WindDirection  <  360  (0  =  north,  90  =  east, 

180  =  south,  270  >=  west) 

Report  (data  flow)  » 

Report_Type 
+  ASCIIJReport  . 
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Appendtt:  HAS  Buoy  Case  Smdy 


Variable  Report  ( Control ledVariable) 

Physicalinterpretation 

vihile  Report_Type*SOS_Report 

broadcasting  data  defined  by  DDE  SOS_Data 
while  Report_Type“Wind_and_Teiiiperature_Report 

broadcasting  data  defined  by  DDE  Hind_and_Teinperature_Data 
while  Report_Type“Weather_History_Report 

broadcasting  data  defined  by  DDE  Heather_History_Data 
while  Report_Type-Airplane_Detailed_Report 

broadcasting  data  defined  by  DDE  Airplane_Detailed_Data 
«diile  Report_Type*»Ship_Detailed_Report 

broadcasting  data  defined  by  DDE  Ship_Detailed_Data 
%diile  Report_Type«None,  no  broadcasting 
Type  Enumeration  -t-  ASCII  Text 

Values  for  Enumeration,  see  Physicalinterpretation 

for  ASCII  Text,  standard  8-bit  ASCII  character 
set 


Dependency  Graph 

The  Core  dependency  graph  in  Figure  13  was  recorded  using  a  ttamwork  level  0  data  flow  diagram. 
Classes  are  illustrated  using  data  transformations.  ‘Runs  and  environmental  variables  on  class  inter¬ 
faces  are  illustrated  using  data  flows  between  transformations.  Input  and  output  variables  are 
illustrated  using  external  input  and  output  data  flows. 

Data  flow  diagrams  were  also  used  to  identify  the  IN,  REQ,  and  OUT  relations  contained  each 
class.  There  is  a  lower  level  data  flow  diagram  (see  Figure  14)  attached  to  each  class  on  the  dependency 
graph  containing  those  relations. 

App33,4  Relations 

IN,  REQ,  and  OUT  relations  were  defined  using  ttzmwork  process  activation  tables.  NAT  relations 
were  defined  textually  in  the  data  dictionary.  'The  following  subsections  contain  examples  of  these 
relations. 

AppJ3.4.1  IN  Relations 

Figure  IS  illustrates  an  example  of  an  IN  relation  for  the  monitored  variable  \^nd 
(IN_Relation_for_Wind).  WndVectorX  and  WindVectorY  are  terms  defined  in  the  data  dictionary. 
l^dSensors  is  the  input  variable  used  to  derive  the  Wind  monitored  variable. 

IN  relations  are  also  needed  for  the  following  monitored  variables: 

•  AirJIfemperature 

•  l^terjlfcmperature 

•  Buoy_Location 

•  Vessel_Request 

•  Emergen<y_Button 
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HAS  Buoy  Cmc  Study 


Appendix:  HAS  Buoy  Case  Study 


2-s2;S 

IN  Relaikm  for 


CwMUtionl 


CowUlionl 


^^WisdS«aaon(Cl)s|  WBdSensor*(C2)s  |  lMndScns«n(C3)s  |  WiBdScason(C4)> 


WlwIVMtorX  »  0  WfaMl\tetorY  >«  0 


WlwlVMlarX>-0 


WimnbclorY 


WlndVeetorX  <  0  VViiidVectorY>«0  •  |  WbdVKtorY 


WlBdVedorX  <  0  WlndVrctorY  <0  •  • 


WiwiVectorX 


ABSfWIndVKtorY)  WIwIVeGlorX 


0 


ABS(WlBd\tetorY) 


ABSfWIadVectorX) 


ABS(WliidVMtarX) 


Figure  IS.  Examine  of  an  IN  Relation 


App33.4^  REQ  Relations 


Figure  16  illustrates  an  example  of  a  REQ  relation  (REQ_Relation_for_Report)  that  maps  multiple 
monitored  variables  to  the  controlled  variable  Report. 


5-sl;10 

REQ_Relation_for_RepQrt 


Event 

TT 
1  1 
1  • 

H 

ItepoitiReport_iypc 

@T((Tiaie  MOO  tfO]  «  0)  when  InModc(SOS) 

lA 
1 1 
1 1 

“SOS_Report» 

@T(niBC  MOO  60]  >  0)  when  InModefNonuI) 

i 

'‘\Mnd_aad_Ttniperaturc_IUport’* 

@T(VeuelReqocet » ■*AiipUne_Oetailcd_Rcpoit_Reqnest**) 

1  • 
1  • 
1 1 

‘MifplaaeJDetai]cd_Rcport’* 

@T(VenclReqacet  w  ”SUp_Octafled_lteiMrt_Rcqveet*^ 

1 1 
1 1 

‘Wp_Oelailcd_Repori** 

@T(VessclBcqncst  =  ’*Hbtoty_Rc|MNt<_Iteqiicat”) 

‘<Weatbcr_History_Report’* 

RcportASCn_Rcport 


ASCU(SOS_Dato) 


ASCIUAiiplane.DctaUed.DaU) 


ASCUOVeaOMr.Histafy.DaU) 


Figure  16.  Example  an  REQ  Relation 

A  REQ  relation  is  also  needed  for  the  controlled  variable  RedLight. 

App  J  OUT  Relations 

Figure  17  illustrates  an  example  of  an  OUT  relation  (OUT_Relation_for_RedLight).  An  OUT 
relation  is  also  required  for  the  controlled  variable  Report. 


8-a2;6 

OUT_Relation_for_RedLight 


Light_Switch 

1  RedLight 

L. 

1 

Light_On 

1  “On” 

1 

Light.Off 

— 

1  «off” 

Figure  17.  Example  an  OUT  Relation 
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Apptadfcc  HAS  Bwoy  Cue  Study 


NATRclatiMS 

Exan^es  of  NAT  relations  for  the  HAS  Buoy  system  are  shown  below: 

-100  <*  AlrTenperature  <>■  100  (degrees  centigrade) 

0  <"  HindHagnitude  <«  250  (nautical  Biles  per  hour) 

AgipJiJiS  Terms 

Ibrms  were  specified  using  data  dictionary  entries.  Some  examples  of  term  definitions  are  shown 
below: 

AveragedAlrTenperature  (data  flow)  * 


AveragedAirTemperature  t  TEMPERATURE 

?«  ROUND  (  (SUM  i:  0  <■  i  <“  5  s:  AirTeBperature(t-10*i)  /  6  )  ] 

Wind_and_Tenqperature_Data  (data  flow)  «■ 

*  Nind__and_Ten^erature  can  be  expressed  as  a  function  of  tine  t,  where 
irind_and_Tenperature_Data  (t)  »  the  set  including  each  of  the 
following  at  tine  t:  * 

{  Buoylfocation 

+  AveragedHaterTenperature 
+  AveragedAirTea^erature 
■¥  AveragedWindDirection 
■¥  AveragedHindMagnitude  }  . 

App3J5j6  Thning  and  Accoraqr  Constraints 

Uming  and  accuracy  constraints  were  specified  using  data  dictionary  entries  attached  to  each  IN, 
OUX  and  REQ  relation.  Each  relation  has  a  body  of  tmd  with  the  sxdGfix  "Jllming”  attached  to  the 
appropriate  teamworfc  process  activation  table.  Ilie  data  dictionary  entries  associated  with  these 
b^es  of  text  specify  timing  and  accurate  constraints.  Examples  are  shown  below: 

Wind_Sen8or_Tining  (data  flow)  « 

Periodic  (sensorjoffset, 

30.0  second  period, 

1.0  second  delay). 


The  wind  sensor  values  are  updated  every  30  seconds,  but  the  value 
is  up  to  1  second  old  by  the  tine  the  software  gets  it. 

Report_Tining  (data  flow) 

Periodic  (8tartup_off8et  30  seconds, 

60.0  second  period, 

5.0  second  delay) 

and 

Denand  (8tartup_offset, 

report_request  (Report_Type) , 
reporting_delay  (Report_Type) ) . 
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Appendo:  HAS  Buoy  Cmc  Study 


Reports  are  generated  regulaurly,  but  special  reports  can  also  be 
requested. 

reporting_delay  (data  flow)  •• 

«dien  Airplane_Oetailed_Report  »>  2.0  odLnutes; 
vdien  Ship_Oetalled_Report  «>  5.0  minutes; 
when  Weather_Bistory_Report  ->  6.0  ndnutes; 


Bach  kind  of  report  requires  a  different  response  time  based  on 
the  time  the  platform  will  be  in  range. 


App3.4  Input  and  Output  Variable  DEFiNinoNS 

Input  and  output  variables  were  specified  using  data  dictionary  entries.  Some  examples  of  input  and 
oul|mt  variable  definitions  are  shown  below: 

AixrTen^ratureSensor  (data  flow)  » 


Dataltem 

Hardware 

Values 

DataTransfer 

DataRepresentation 


AirTen^eratureSensor 

Air  ten^rature  sensor 

-128  <«  AirTeii^eratureSensor  <*■  127 

Port  B 

8-bits,  two '8-complement  integer 


Batton_Xndicator  (data  flow)  « 


Dataltem 

Hardware 

Values 

DataTransfer 

DataRepresentation 


Button_Indicator 
Emergency  button  on  buoy 
Pressed  (1)  or  released  (0) 

Port  B 

Most  significemt  bit  (bit  0)  of  the  8-bit  port: 
2#lxxxxxxx#  <■  Pressed, 

2#0xxxxxxx#  «  Released. 


Ootgoing_Radlo_Message  (data  flow)  » 


Dataltem 

Hardware 

Values 


Outgoing_Radio_Mes  sage 
Radio  transmitter 
SOS_Report, 

Wind_and_Temperature_Report , 
Airplane_petailed_Report , 
Ship_petailed_Report , 
Weather_His  tory_Report , 

None. 


DataTransfer  Port  G 

DataRepresentation  512  bytes: 

Byte  1:  2#10000001#  means  bytes  3-512  contain  a  page  of  an  SOS_Report 
2#10000010#  means  bytes  3-512  contain  a  page  of  a 
Wind_and_Teii^erature_Report 
2#10000011#  means  bytes  3-512  contain  a  page  of  an 
Airplane_Detailed_Report 
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2#10000100#  laeans  bytes  3-512  contain  a  page  of  a 
Shlp_Detailed_Report 

2#10000101#  iseans  bytes  3-512  contain  a  page  of  a 
Weather_History_Report 

2#0xxxxxxx#  Bksans  Hone  -  no  SMSssage  is  be  transisitted  (ignore 
bytes  2-512) 

Byte  2t  Bits  0-3:  4-bits  range  1  ..  16  representing  total  nunber  of 

pages  in  siessage 

Bits  4-7 :  4-bits  range  1  . .  16  representing  number  of  page 
being  transmitted 

Bytes  3-512:  Message  represented  by  ASCII  characters. 

End  of  message  represented  by  16#7F#. 


App3.5  Mode  Classes 

Mode  classes  were  defined  usiqg  teamworfcstate-transition  diagrams.  There  was  only  one  mode  dass 
for  the  HAS  Buoy  (M'oblem  (see  Figure  18). 


Mode_Clas_far_Syatein_Mode 

SOS 

10 

1 

Biitton_Presscd 

k 

_ 3 

TcnBliiate_SOS^Signal 

Normal 

4 _ 

Figure  18.  HAS  Buoy  Mode  das 


UST  OF  ABBREVIATIONS  AND  ACRONYMS 


ADARTS 

Ada-based  Design  Approach  for  Real-Time  Systems 

CASE 

computer-aided  software  engineering 

CDIF 

CASE  Data  Interdiange  Format 

Core 

Consortium  Requirements  ^igineering 

ERA 

entity-relationship-attribute 

HAS 

Host-at-Sea 

IN 

input  (Core’s  abbreviation  for  “input”  relations) 

NAT 

natural  (CoRE’s  abbreviation  for  “natural”  relations) 

luL 

no  date 

OUT 

output  (CoRE’s  abbreviation  for  “output”  relations) 

p-^)ec 

process  specification 

RDD 

Requirements  Driven  Design 

REQ 

required  (CoRE’s  abbreviation  for  “required”  relations) 

SEN 

System  Engineering  Notebook 
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